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-leave@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/