On Fri, Mar 4, 2022 at 12:48 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. > So does that mean you want to list the Linux distros explicitly? Or you want to explicitly list the glibc version? > > > 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. > That's fine by me if others agree. > > > > 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. > Based on other replies it sounds like that's what people want. > > > > 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. > Then what more would you want than what's listed in PEP 7 already? > > 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. > I think that depends on the person supporting the platform.
_______________________________________________ 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/V2SLVKWYW3PSKPD3HI6QFJDSXD526TFR/ Code of Conduct: http://python.org/psf/codeofconduct/
