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.