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.
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. Christian