On 04/03/2022 21.41, Brett Cannon wrote:

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?

I want to explicitly mention glibc and Linux distro for manylinux binary wheels standards that are supported by PyPI. For the rest we should be a bit more hand-wavy. Maybe we can point to our list of stable buildbots?

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?

Nothing in particular other than a link to the PEP, so people can discover the requirement more easily. Christian

On Fri, Mar 4, 2022 at 9:49 AM Christian Heimes <christian@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-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/5LDLSPQV... Code of Conduct: http://python.org/psf/codeofconduct/

-- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat

On Fri, Mar 4, 2022 at 1:32 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:

On 4 Mar 2022, at 00:30, Brett Cannon <brett@python.org> wrote:

Do we officially support NetBSD? Do you know how to find out if we do? You might think to look at https://www.python.org/dev/peps/pep-0011/#supporting-platforms , but that just loosely defines the criteria and it still doesn't list the actual platforms we support. (BTW I don't know if we do officially support NetBSD, hence this email.)

I think we should clarify this sort of thing and be a bit more upfront with the level of support we expect/provide for a platform. As such, I want to restructure PEP 11 to list the platforms we support, not just list the platforms we stopped supporting. To do this I want define 3 different tiers that outline what our support requirements and promises are for platforms.

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.

What’s the difference between Tier 1 and 2 other than that PRs are checked with tier 1 platforms before committing and with tier 2 afterwards?

Everyone on the core team supports tier 1, while for tier 2 there's only those who specifically volunteer to support it.

In particular, tier 1 contains windows server and not desktop (even though I expect that those are compatible as far as our use is concerned), and does not contain the macOS versions that we actually support in the installers on python.org (macOS 10.9 or later, both x86_64 and arm64). AFAIK support for macOS 10.9 in the python.org installers is now primarily, if not only, tested by Ned. That could, and probably should, be automated but that’s a significant amount of work.

So macOS 10.9 would be tier 3. There's nothing wrong with that, just we obviously don't know when it fails now anyway, so it technically only holds up a release so much as Ned as RM for macOS builds can choose to.

[…]

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.

CTypes is hardware specific, although through libiff. There’s also intermittent discussions about support for ancient hardware platforms. Would we block a release when (for example) support for Linux on sparc32 is broken?

If it's tier 2 or higher, yes. -Brett

Ronald

—

Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/

On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin <encukou@gmail.com> wrote:

On 04. 03. 22 0:30, Brett Cannon wrote:

...

Do we officially support NetBSD? Do you know how to find out if we do? You might think to look at https://www.python.org/dev/peps/pep-0011/#supporting-platforms <https://www.python.org/dev/peps/pep-0011/#supporting-platforms> , but that just loosely defines the criteria and it still doesn't list the actual platforms we support. (BTW I don't know if we do officially support NetBSD, hence this email.)

I think we should clarify this sort of thing and be a bit more upfront with the level of support we expect/provide for a platform. As such, I want to restructure PEP 11 to list the platforms we support, not just list the platforms we stopped supporting. To do this I want define 3 different tiers that outline what our support requirements and promises are for platforms.

While you're at it: consider moving the lists to the devguide, so the PEP would only contain the general process & criteria.

Why the devguide? I view the list of platforms as important for public consumption as for the core dev team to know what to (not) accept PRs for.

...

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.

Do we need two core devs to revert changes?

No, but consider you are trying to land something before b1 and a tier 2 platform keeps failing. You have no idea why, but e.g. Victor is on vacation and is unavailable to help. I personally wouldn't want to wait until the next version of Python just because a platform we say we support had its expert take an inconvenient vacation.

What are the duties of someone listed for a platform, anyway?

I would expect they would be the reviewer of PRs for that platform. Also domain expert to help out with questions as they arise if their platform could potentially block a release or feature getting in.

...

Tier 3 are platforms we accept PRs for to keep working, but they won't block a release. At least one core dev must be listed to be in charge of PRs that affect the platform. A buildbot would be nice but not required. I'm thinking either historical platforms we support or something like Emscripten that's working towards being a tier 2 platform. I'm not sure if we want to have explicit approval to be in this tier beyond the outlined requirements, but obviously if a core dev isn't keeping up with PRs then the platform will be dropped.

All other platforms we do not directly support in the repository and it is up to the community to keep functioning. We can obviously keep accepting general patches to up compatibility, but platform-specific patches for anything outside of these tiers wouldn't. No issue if someone provides a buildbot for their own benefit, but these buildbots would never hold anything up.

When a Python version hits b1, then that platform is considered supported for that version as long as the requirements outlined above continue to be met. Once the Python version hits EOL then like anything, support ends no matter what. We could capture the supported platforms for a version in the release schedule PEP if people want > I would expect appropriate labels being added to the builders listed at https://buildbot.python.org/all/#/builders <https://buildbot.python.org/all/#/builders> to signify which platforms we block releases for (e.g. `tier-1,`, `tier-2`, or `release-blocker` as a generic label).

I would expect PEP 11 to list the appropriate C symbol that's set for that platform, e.g. __linux__.

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.

IMO it would be good to be explicit wrt. testing and support. There's a lot of arch/compiler assumptions still hidden in the codebase.

👍 As I replied to Christian, it seems people want explicit CPU architectures listed. -Brett

...

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.

I think it would be good to move that here. It's a “platform support” matter, not “code style”.

...

FYI the tier support idea and the rough definitions above come from Rust: https://doc.rust-lang.org/nightly/rustc/platform-support.html <https://doc.rust-lang.org/nightly/rustc/platform-support.html> .

_______________________________________________ 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/ZPBSHENP... Code of Conduct: http://python.org/psf/codeofconduct/

---

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/QXH2ZTE2... Code of Conduct: http://python.org/psf/codeofconduct/

On 07/03/2022 18.02, Petr Viktorin wrote:

...

Why the devguide? I view the list of platforms as important for public consumption as for the core dev team to know what to (not) accept PRs for.

So, let's put it in the main docs? Yes, I guess the devguide is a weird place to check for this kind of info. But a Python enhancement proposal is even weirder.

+1 for our main docs (cpython/Doc/) Platform support is Python versions specific. Python 3.10 may support different version than 3.11 or 3.12. It makes sense to keep the support information with the code. Christian

On 08. 03. 22 0:30, Brett Cannon wrote:

On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes <christian@python.org <mailto:christian@python.org>> wrote:

On 07/03/2022 18.02, Petr Viktorin wrote: >> Why the devguide? I view the list of platforms as important for public >> consumption as for the core dev team to know what to (not) accept PRs >> for. > > So, let's put it in the main docs? > Yes, I guess the devguide is a weird place to check for this kind of > info. But a Python enhancement proposal is even weirder.

+1 for our main docs (cpython/Doc/)

Platform support is Python versions specific. Python 3.10 may support different version than 3.11 or 3.12. It makes sense to keep the support information with the code.

Technically it's CPython version-specific. I also don't know where we would list this in the docs. Looking at https://docs.python.org/3/ <https://docs.python.org/3/> I wouldn't know where to look for such information.

Yeah, I kind of have the same issue with backcompat expectations (https://discuss.python.org/t/documenting-python-versioning-and-stability-exp...). We might need a new section for this kind of CPython-specific docs. Maybe repurpose the "Python Setup and Usage" section, which is CPython-specific already.

On Fri, Mar 11, 2022 at 6:21 PM Victor Stinner <vstinner@python.org> wrote:

But I don't know how to get this info from the Microsoft documentation. I usually dig into Wikipedia articles to check which Windows version is still supported or not, but I'm confused between "mainstream support" and "extended support".

As PEP 11 states, it is the extended support time-frame that is of interest.

For example, which Python version still support Windows 7? Wikipedia says that Windows 7 mainstream support ended in 2015, and extended support ended in 2020. But Python still has a Windows 7 SP1 buildbot for Python 3.8: https://buildbot.python.org/all/#/builders/60

Python 3.8.0 was release when Windows 7 SP1 was within the extended support time-frame. Therefore, Win7 is supported (and tested) until 3.8 reaches EOL.

What is the minimum Windows supported by Python 3.10?

From the link listed in PEP 11, Windows 8.1 does not leave extended support until Jan 10, 2023. So it seems that 3.10 and 3.11 will need to support Windows 8.1. -- Jeremy Kloth

On 3/14/22 20:31, Brett Cannon wrote:

On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner <vstinner@python.org> wrote:

It would be great to have the list of supported platforms per Python version!

I could see the table in PEP 11 being copied into the release PEPs.

By "release PEPs", you mean the release schedule PEPs, like PEP 619 "Python 3.10 Release Schedule"? https://peps.python.org/pep-0619/ Because, yeah, I think that would be the best place for it. Though then maybe the name of the PEP should change, as the document is doing double duty. //arry/