On Fri, Mar 4, 2022 at 9:49 AM Christian Heimes <christ...@python.org> wrote:
> Hi Brett, > > thanks for starting the discussion! Much appreciated. > > On 04/03/2022 00.30, Brett Cannon wrote: > > Tier 1 is the stuff we run CI against: latest Windows, latest macOS, > > Linux w/ the latest glibc (I don't know of a better way to define Linux > > support as I don't know if a per-distro list is the right abstraction). > > These are platforms we won't even let code be committed for if they > > would break; they block releases if they don't work. These platforms we > > all implicitly promise to support. > > > > Tier 2 is the platforms we would revert a change within 24 hours if they > > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older > > glibc.This is historically the "stable buildbot plus a core dev" group > > of platforms. The change I would like to see is two core devs (in case > > one is on vacation), and a policy as to how a platform ends up here > > (e.g. SC must okay it based on consensus of everyone). The stable > > buildbot would still be needed to know if a release is blocked as we > > would hold a release up if they were red. The platform and the core devs > > supporting these platforms would be listed in PEP 11. > > I would like to see an explicit statement about glibc compatibility. > glibc's API and ABI is very stable. We have autoconf feature checks for > newer glibc features, so I'm not overly concerned with breaking > compatibility with glibc. Anyhow we should also ensure that we are > backwards compatible with older glibc releases that are commonly used in > the community. > > Therefore I propose that we target the oldest manylinux standard > accepted by PyPI, for which the operating system has not reached its > EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June > 2024. We could also state that we aim for compatibility with oldest > Debian Stable and Ubuntu LTS with standard, free security updates. As of > today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions with > regular updates. > > > Apropos libc, what is our plan concerning musl libc (Alpine)? It's a > popular distro for containers. CPython's test suite is failing on latest > Alpine (https://bugs.python.org/issue46390). Some of the problems seem > to be caused by issues or missing features in musl libc. I like to see > the problems fixed before we claim basic support for Alpine. > > > > I would expect PEP 11 to list the appropriate C symbol that's set for > > that platform, e.g. __linux__. > > For POSIX-like OS I would rather follow the example of Rust and use > platform target triplet. The triplet encodes machine (CPU arch), vendor, > and operating system. The OS part can encode libc. For example > x86_64-*-linux-gnu for "x84_64 arch", "any vendor", and "Linux with GNU > libc (glibc)". Commands like ./config.guess or gcc -dumpmachine return > the current triplet. > > The target triplet is used by autoconf's ./configure script a lot. > > > > I don't know if we want to bother listing CPU architectures since we are > > a pure C project which makes CPU architecture less of a thing, but I'm > > personally open to the idea of CPU architectures being a part of the > > platform definition. > > I strongly recommend that we include machine architecture, too. We have > some code that uses machine specific instructions or features, e.g. > unaligned memory access. We cannot debug problems on CPU archs unless we > have access to the hardware. > > Agreed, there have been various architecture specific bugs in the past and the buildbots provide good coverage in that respect. > > > I don't think we should cover C compilers here as that's covered by PEP > > 7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists > > compilers and their versions. > > We should say something about compilers. I wouldn't list compiler > versions, though. Compiler features like C99 support should be sufficient. > > Do we target the platform's default compiler or are we targeting the > latest compiler that is officially supported for the platform? CentOS 7 > comes with an old GCC, but has newer GCC versions in SCL (Developer > Toolset 8). I'm asking because CentOS 7's default gcc does not support > stdatomic.h. The official manylinux2014 OSCI container image ships GCC > from devtoolset-8. > > That's an interesting question and RHEL7 is a bit of a special case. If mimalloc, for example, will be used in CPython, RHEL7/CentOS7 support is out of the question in regards to its default compiler. I've already changed the config to some RHEL7 buildbots to use a later GCC version through the Developer Toolset 8, so GCC 8. The latest Python shipped through Red Hat Software Collection channels in RHEL7 is Python 3.8, built using Developer Toolset 9 (GCC 9). However, me and David Edelsohn are the only ones providing RHEL7 buildbots, so coordinating a change to all the configs to use a later GCC version should be easy enough. Another thing to consider is since PEP644 was implemented, it's not possible to compile the _hashlib and _ssl modules on RHEL7 from Python >= 3.10. RHEL7's official maintenance support phase ends at June 30, 2024, which can be considered its EOL (followed by the extended life cycle support, but that's not relevant for this discussion). Now I don't have a strong opinion here and I think targeting what manylinux2014 is targeting, is a good option till RHEL7 goes out of support, or even earlier than that should manylinux change the requirements. > Christian > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/5LDLSPQVYLVKNEJADOFBQQ3TKBCFEDEV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WUBX4B6I5R7EIYDPAVIYANS6ZQPHR64B/ Code of Conduct: http://python.org/psf/codeofconduct/
