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

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.

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? What are the duties of someone listed for a platform, anyway?

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.

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/

On Fri, Mar 4, 2022 at 12:48 AM Christian Heimes 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.

On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin 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 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 Mon, Mar 7, 2022 at 11:01 AM Christian Heimes wrote:

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?

How about we list Linux support as based on the libc implementation and version and point as various stable buildbots that cover that libc?

...

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.

👍

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

On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes 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.

It would be great to have the list of supported platforms per Python version! Maybe supporting new platforms and dropping support for a platform should be document in What's New in Python x.y. GCC does that for example. It also *deprecates* support for some platforms. Example: https://gcc.gnu.org/gcc-9/changes.html -- It's always hard for me to know what is the minimum supported Windows version. PEP 11 refers to Windows support: https://peps.python.org/pep-0011/#microsoft-windows 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". 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 What is the minimum Windows supported by Python 3.10? Victor On Mon, Mar 7, 2022 at 8:06 PM Christian Heimes 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.

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

-- Night gathers, and now my watch begins. It shall not end until my death.

On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner 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.

Maybe supporting new platforms and dropping support for a platform should be document in What's New in Python x.y. GCC does that for example. It also *deprecates* support for some platforms. Example: https://gcc.gnu.org/gcc-9/changes.html

--

It's always hard for me to know what is the minimum supported Windows version. PEP 11 refers to Windows support: https://peps.python.org/pep-0011/#microsoft-windows

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

It's "free with purchase" and "pay us more and we will keep supporting you". You can think of it as standard versus extended warranties. https://docs.microsoft.com/en-us/lifecycle/policies/fixed

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

Just because we have a buildbot does not mean we support it. All it means is someone in the community cares enough about Windows 7 to want to know when CPython no longer works.

What is the minimum Windows supported by Python 3.10?

I believe it's Windows 8. https://docs.microsoft.com/en-us/lifecycle/faq/windows https://docs.microsoft.com/en-us/lifecycle/products/windows-81 -Brett

Victor

On Mon, Mar 7, 2022 at 8:06 PM Christian Heimes 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.

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/LJID7Y7R...

...

Code of Conduct: http://python.org/psf/codeofconduct/

-- Night gathers, and now my watch begins. It shall not end until my death.

On Mon, Mar 14, 2022 at 11:18 PM Larry Hastings wrote:

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

On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner 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/

Yep!

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.

👍