[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

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

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 4, 2022 at 1:32 AM Ronald Oussoren 
wrote:

>
>
> On 4 Mar 2022, at 00: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 , 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/
>
>
___
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/PQQSPHK6HSOGYCFJ6NIVMJJISSWNYU3Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2022-02-25 - 2022-03-04)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7224 ( +4)
  closed 51425 (+62)
  total  58649 (+66)

Open issues with patches: 2938 


Issues opened (48)
==

#44807: typing.Protocol silently overrides __init__ method of delivere
https://bugs.python.org/issue44807  reopened by gvanrossum

#46623: test_zlib: test_pair() and test_speech128() fail with s390x ha
https://bugs.python.org/issue46623  reopened by petr.viktorin

#46823: Add LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE combined opcode
https://bugs.python.org/issue46823  reopened by brandtbucher

#46858: mmap constructor resets the file pointer on Windows
https://bugs.python.org/issue46858  opened by benrg

#46860: `--with-suffix` not respected on case-insensitive file systems
https://bugs.python.org/issue46860  opened by brett.cannon

#46862: subprocess makes environment blocks with duplicate keys on Win
https://bugs.python.org/issue46862  opened by benrg

#46863: Python 3.10 OpenSSL Configuration Issues
https://bugs.python.org/issue46863  opened by adam

#46864: Deprecate ob_shash in BytesObject
https://bugs.python.org/issue46864  opened by methane

#46868: Improve performance of math.prod with bignums (and functools.r
https://bugs.python.org/issue46868  opened by benrg

#46870: Improper Input Validation in urlparse
https://bugs.python.org/issue46870  opened by P0cas

#46872: Odd handling of signal raised if an illegal syscall is attempt
https://bugs.python.org/issue46872  opened by bup

#46878: [sqlite3] remove "non-standard" from docstrings
https://bugs.python.org/issue46878  opened by erlendaasland

#46879: [doc] incorrect sphinx object names
https://bugs.python.org/issue46879  opened by push-f

#46880: zipfile library doesn't extract windows zip files properly on 
https://bugs.python.org/issue46880  opened by nimrodf

#46881: Statically allocate and initialize the latin1 characters.
https://bugs.python.org/issue46881  opened by kumaraditya303

#46882: Clarify argument type of platform.platform(aliased, terse) to 
https://bugs.python.org/issue46882  opened by Rotzbua

#46883: Add glossary entries to clarify the true/True and false/False 
https://bugs.python.org/issue46883  opened by steven.daprano

#46884: [doc] msilib.rst uses data directive to document modules
https://bugs.python.org/issue46884  opened by push-f

#46885: Ensure PEP 663 changes are reverted from 3.11
https://bugs.python.org/issue46885  opened by pablogsal

#46887: ./Programs/_freeze_module fails with MSAN: Uninitialized value
https://bugs.python.org/issue46887  opened by vstinner

#46888: SharedMemory.close() destroys memory
https://bugs.python.org/issue46888  opened by ronny-rentner

#46890: venv does not create "python" link in python 3.11
https://bugs.python.org/issue46890  opened by ronaldoussoren

#46892: Async Call-Stack Reconstruction
https://bugs.python.org/issue46892  opened by mpage

#46893: Allow extensions to set the vectorcall field on instances of P
https://bugs.python.org/issue46893  opened by itamaro

#46895: Allow extensions to set a callback to be invoked when a type i
https://bugs.python.org/issue46895  opened by mpage

#46896: add support for watching writes to selected dictionaries
https://bugs.python.org/issue46896  opened by carljm

#46897: Add API to allow extensions to set callback function on creati
https://bugs.python.org/issue46897  opened by mpage

#46898: Add API to allow extensions to set callback function on creati
https://bugs.python.org/issue46898  opened by mpage

#46899: use of uninitialized value with msan from subprocess_fork_exec
https://bugs.python.org/issue46899  opened by yilei

#46901: Deprecate and eventually remove macOS-only PYTHONEXECUTABLE en
https://bugs.python.org/issue46901  opened by ned.deily

#46902: Typo hint message for from-imports?
https://bugs.python.org/issue46902  opened by Jean_Abou_Samra

#46903: Crash when setting attribute with string subclass as the name 
https://bugs.python.org/issue46903  opened by ronaldoussoren

#46904: Python Decimal supports '#' format, C Decimal does not.
https://bugs.python.org/issue46904  opened by const

#46905: winsound.PlaySound should accept pathlib.Path instances
https://bugs.python.org/issue46905  opened by Julian-O

#46906: Add PyFloat_(Pack|Unpack)(2|4|8) to the public C API
https://bugs.python.org/issue46906  opened by methane

#46907: Update Windows and MacOS installer to SQLite 3.38.0.
https://bugs.python.org/issue46907  opened by felixxm

#46908: Debugger jumps to a wrong instruction in for loop
https://bugs.python.org/issue46908  opened by franarenasafan

#46911: Early tracing has lineno=None for modules
https://bugs.python.org/issue46911  opened by nedbat

#46912: Full gc collection blocked from collecting after some amount o
https://bugs.python.org/issue46912  opened by al3x3i.k

[Python-Dev] Re: Improvements to the sys.path initialization documentation

[Russel Webber]

 Hi,
I will add a link to
https://docs.python.org/dev/c-api/init_config.html#python-path-configuration
as we're trying to at least mention every way sys.path can be initialised.
I think the audience for the C API docs are likely to be more knowledgeable
than those reading the Setup and Usage section, so I don't believe it will
be possible to merge the information.
Thanks,
Russel

On Thu, 3 Mar 2022 at 12:27, Victor Stinner  wrote:

> Hi,
>
> I tried to document inputs and outputs of Modules/getpath.py in the C
> API Initialization API:
>
> https://docs.python.org/dev/c-api/init_config.html#python-path-configuration
>
> I don't know if it would be possible to merge most of these
> information at a single place to avoid oudated documentation.
>
> Victor
>
> On Wed, Mar 2, 2022 at 5:40 PM Russel Webber 
> wrote:
> >
> > Hi All,
> >
> > Steve Dower, Eryk Sun and I have been working on improving the
> documentation around how sys.path is initialised and therefore how Python
> modules are found.
> >
> > We're moving the details from
> https://docs.python.org/3.11/using/windows.html#finding-modules
> > to a platform-agnostic new section in
> https://docs.python.org/3.11/using/cmdline.html
> >
> > We're aiming to have one place in the documentation where all the ways
> to customize sys.path (PYTHONPATH, ._pth, site, etc) are at least mentioned.
> >
> > We'd appreciate further community feedback on the changes before they
> are merged.
> > https://bugs.python.org/issue31582
> > https://github.com/python/cpython/pull/31082
> >
> > Thank you,
> > Russel
> >
> > ___
> > 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/5AZQZH45EUCYN26SVD5DO6O7XTPSTIB5/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
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/4PI4A3GQIFYOH5QCNKYMOOOHL5K6JD7D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: build cpython on M1 Pro mac

[Yves Duprat]

Guido van Rossum wrote:
> On Wed, Mar 2, 2022 at 8:34 AM Yves Duprat ydup...@gmail.com wrote:
> > How did you find that issue?
> > This message printed from VSCode when I ran my script in debug mode
> > Oh, I see, this is something that pydevd prints when it doesn't understand
> the .pyc file. We changed the bytecode significantly in 3.11 (more than we
> did in previous versions, though it tends to change in each version) --
> that message is at least a decade old.
> > the Pydev extension used by VS Code doesn't yet work well with
> > the changes in 3.11 internals.
> > Is there a simple sheet, white paper about these internal changes ?
> > No, you could follow the discussions on
> https://github.com/faster-cpython/ideas though and ask specific questions
> there if something's not clear.
Ok

> > You should probably inquire with either the
> > Pydev extension (https://github.com/fabioz/Pydev) or the VS Code team
> > about
> > what their plans are for fixing this
> > Thank for the solutions.
> > The specific component to  look for is pydevd --
> https://github.com/fabioz/PyDev.Debugger/. I recommend filing an issue
> there.
see: https://github.com/fabioz/PyDev.Debugger/issues/213
see: https://github.com/microsoft/debugpy/issues/861
Thank for your help
___
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/GZDHVUUAIRB7SXQPCQYYXXQEIXBTE3SJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improvements to the sys.path initialization documentation

[Eryk Sun]

On 3/4/22, Victor Stinner  wrote:
> it would be nice to move the last bits of the sys.path initialization
> from the site module to the getpath module. It's unpleasant to
> have a different sys.path depending if the site module is loaded
> or not.

I don't understand. The site packages directories, including virtual
environments, are a site extension.
___
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/5ZO73YHNL3BHXY4MHRITOGOECL2SZKPO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Simon Cross]

+10 on making the tier platform support explicit.

I would vote not to require involving the SC in the tier changes
unless there is a strong reason to do so (e.g. there is controversy,
or e.g. Tier 1 implies a commitment of PSF infrastructure). The SC has
a lot of decisions to make as it is & hopefully Tier 2 and 3 are
really about checking a checklist (are there enough core devs
committed, are the buildbots in place, etc) that is already defined in
the PEP.

Replies to some other replies in the thread:

I like Christian's idea of explicitly supporting platforms such as
manylinux2014, Debian stable, Ubuntu stable where C extensions are
commonly built. It would help make those de facto standards more
official. Or some of the platforms supported by cibuildwheel (to
include non-Linux platforms).

I would prefer having the list in a PEP rather than the devguide. The
devguide is important, but it doesn't feel like a canonical reference
place for this sort of information.

Regards,
Simon
___
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/W5DJ6QAALCJQPC2AYEW36F5VS63KV5MJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Petr Viktorin]

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


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

[Python-Dev] Re: Improvements to the sys.path initialization documentation

[Victor Stinner]

Unrelated to the doc, now that getpath has been rewritten in pure
Python, thanks to Steve Dower!, it would be nice to move the last bits
of the sys.path initialization from the site module to the getpath
module. It's unpleasant to have a different sys.path depending if the
site module is loaded or not.

site handles venv, computes absolute paths and adds the user directory.

Loading customization modules (sitecustomize and usercustomize) should
stay in the site module.

Victor
___
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/4GZZ5PRP5YLZUVE34NYQQNUF4KBNMNNV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Ronald Oussoren via Python-Dev]

> On 4 Mar 2022, at 00: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 
>  , 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?   

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. 

[…]

> 
> 
> 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?  

Ronald

—

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

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

[Python-Dev] Re: Defining tiered platform support

[Christian Heimes]

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