Python ecosystem versions overview

Python ecosystem versions overview

[John Snow]

Hi, recently there was some discussion and debate over what versions
of which things in the Python ecosystem we need to support with
regards to our build platform promise. I don't address those issues in
this mail at all. O:-)

In researching that problem, I created a CLI script to automatically
poll repology and several other sources (homebrew and macports APIs)
to assemble a cohesive overview of the "Python ecosystem" across all
of our target platforms. I felt this was necessary because it's often
quite difficult to determine at a glance what is available as each
platform has quite different ways of packaging, de/bundling, or
factoring these tightly related projects.

Here's the summary output:

nago@fedora ~/s/repology-dashboard (devel)> python3 python_repology.py
Fetching https://repology.org/api/v1/project/python
Fetching https://repology.org/api/v1/project/python%3Asphinx
Fetching https://repology.org/api/v1/project/python%3Asetuptools
Fetching https://repology.org/api/v1/project/setuptools
Fetching https://repology.org/api/v1/project/pip
Fetching https://ports.macports.org/api/v1/ports/py-setuptools/
MacPorts de-facto python version is python313. Results will be narrowed.
FreeBSD de-facto python version is 311. Results will be narrowed.
NetBSD de-facto python version is 312. Results will be narrowed.
Fetching https://formulae.brew.sh/api/formula/python@3.13.json
Homebrew de-facto python version is python@3.13. Results will be narrowed.

...

========
overview
========
distro              python3  pip     setuptools  sphinx  repos
-------------------------------------------------------------------------------------------------------
alpine_3_19         3.11.13  23.3.1  70.3.0      6.2.1   main,
community
alpine_3_20         3.12.11  24.0    70.3.0      7.2.6   main,
community
alpine_3_21         3.12.11  24.3.1  70.3.0      8.1.3   main,
community
alpine_3_22         3.12.11  25.1.1  80.9.0      8.2.3   main,
community
centos_stream_9     3.9.23   21.3.1  53.0.0      3.4.3   BaseOS, CRB
centos_stream_10    3.12.11  23.3.2  69.0.3      7.2.6   BaseOS, CRB
debian_12           3.11.2   23.0.1  66.1.1      5.3.0   bookworm/main
fedora_40           3.12.10  23.3.2  69.0.3      7.2.6   updates,
release
fedora_41           3.13.5   24.2    69.2.0      7.3.7   updates,
release
fedora_42           3.13.5   24.3.1  74.1.3      8.1.3   updates,
release
freebsd             3.11.13  23.3.2  63.1.0      5.3.0   ---
homebrew            3.13.5   ---     80.9.0      8.2.3   ---
macports            3.13.5   25.1.1  78.1.1      8.2.3   ---
openbsd             3.12.11  25.1.1  79.0.1      8.2.3   ---
opensuse_leap_15_6  3.6.15   20.0.2  44.1.1      2.3.1   updates/sle,
main/oss
pkgsrc_current      3.12.11  25.1.1  80.9.0      8.2.3   ---
ubuntu_22_04        3.10.12  22.0.2  59.6.0      4.3.2
jammy-updates/main, jammy/universe, jammy/main
ubuntu_24_04        3.12.3   24.0    68.1.2      7.2.6   noble/main,
noble/universe
ubuntu_24_10        3.12.7   24.2    74.1.2      7.4.7
oracular/main, oracular/universe
ubuntu_25_04        3.13.3   25.0    75.8.0      8.1.3   plucky/main,
plucky/universe

Some notes and observations:

(1) Homebrew doesn't have a pip version listed because technically
Homebrew does not ship pip; it's bundled directly with python. I did
not find any reasonable mechanism to determine what that version is.
However, as part of a "ports" style collection, it's usually bleeding
edge and not likely to run afoul of "too old to reasonably support".

(2) Alpine doesn't ship pip except via its "community" repo. I am
unclear on if this is a repository enabled by default or not.

(3) CentOS stream does not ship "sphinx" except via "CRB", which I
think may not be enabled by default.

(4) OpenSUSE Leap 15.6 is egregiously old. 16.x is promised for later
this year, but we are past the promised "five year" support window for
this platform in some sense -- 15.0 released in 2018 -- so I believe
it can actually be ignored. Even though we still have a (working)
dockerfile for it, and I see value in supporting SUSE in general,
future python subsystem decisions may opt to exclude SUSE as a
first-tier supported platform as per our policy. (It is also possible
to pull in newer packages from different streams, but I was unable to
investigate this in detail at this time.)

(5) Ubuntu only ships pip in "universe", but also ships some Python
3.x interpreter updates to that repository as well. I have filtered
this list to only use Universe for pip packages, leaving Python the
base version that ships with the platform in x/main or x-updates/main.

(6) "ports" collections (FreeBSD, NetBSD, OpenBSD/pkgsrc_current,
Homebrew and MacPorts) do not necessarily have the concept of a
platform default Python interpreter version, but other packages in the
collection can be used as a heuristic to determine which one is best
suited.

For instance, FreeBSD and NetBSD only ship pip et al for a single
interpreter version.
OpenBSD has a symbolic "python3" package that installs a specific
version. Homebrew has a "python3" alias that chooses a specific Python
interpreter version. MacPorts similarly has a symbolic "py-setuptools"
package that will choose a specific interpreter version.

These are used as heuristics to determine a "de-facto" default for the
ports collection platforms.

-

That's all for now. I will publish the script to the list later,
though I have no intention of cleaning it up for inclusion in our
tree. When I send it, bookmark the email if you'd like to try using
this for other purposes or running it for yourself. Maybe I will throw
it up on my personal GitLab in case it is useful to other subsystem
maintainers in the future. The filtering code is a little messy, but
it got the job done and should be reasonably straightforward to make
sense of at a glance. It uses only the 'requests' library as a third
party dependency.

Your humble Python sin-eater,
--js

Re: Python ecosystem versions overview

[Paolo Bonzini]

On 7/8/25 22:36, John Snow wrote:
> centos_stream_9     3.9.23   21.3.1  53.0.0      3.4.3   BaseOS, CRB

Ok, so the lowest version of Sphinx (3.4.3) is currently used for CentOS 
Stream 9.  It's supported for roughly 2 more years, until 12.0.

> opensuse_leap_15_6  3.6.15   20.0.2  44.1.1      2.3.1   updates/sle,

We use the 3.11 runtime in the dockerfile, see 
tests/lcitool/mappings.yml.  That is a bare minimum install, so 
configure won't use the distro sphinx and instead use 5.3.0 from 
pythondeps.toml.

> main/oss
> pkgsrc_current      3.12.11  25.1.1  80.9.0      8.2.3   ---
> ubuntu_22_04        3.10.12  22.0.2  59.6.0      4.3.2
> jammy-updates/main, jammy/universe, jammy/main

This is the second oldest version of Sphinx.

> ubuntu_24_04        3.12.3   24.0    68.1.2      7.2.6   noble/main,
> noble/universe
> ubuntu_24_10        3.12.7   24.2    74.1.2      7.4.7
> oracular/main, oracular/universe
> ubuntu_25_04        3.13.3   25.0    75.8.0      8.1.3   plucky/main,
> plucky/universe
> 
> (3) CentOS stream does not ship "sphinx" except via "CRB", which I
> think may not be enabled by default.

It's not, but it's intended to be enabled when developing against the 
Red Hat packages.  We enable it in the dockerfile:

     dnf config-manager --set-enabled -y crb

> (4) OpenSUSE Leap 15.6 is egregiously old. 16.x is promised for later
> this year, but we are past the promised "five year" support window for
> this platform in some sense -- 15.0 released in 2018 -- so I believe
> it can actually be ignored.

As far as Python is concerned, OpenSUSE 15 doesn't cause trouble anyway, 
because we do not use the 3.6 interpreter and its very old distro packages.

So that's two reasons to ignore OpenSUSE.

> (5) Ubuntu only ships pip in "universe", but also ships some Python
> 3.x interpreter updates to that repository as well. I have filtered
> this list to only use Universe for pip packages, leaving Python the
> base version that ships with the platform in x/main or x-updates/main.

Yes, fair enough.  Ubuntu 22.04 came out more recently than CentOS 
Stream 9, after all, and its base distribution is more up to date than 
CS9 with respect to the Python ecosystem.  Rust is where Ubuntu (both 
22.04 and 24.04) is considerably less updated.

Paolo

> (6) "ports" collections (FreeBSD, NetBSD, OpenBSD/pkgsrc_current,
> Homebrew and MacPorts) do not necessarily have the concept of a
> platform default Python interpreter version, but other packages in the
> collection can be used as a heuristic to determine which one is best
> suited.
> 
> For instance, FreeBSD and NetBSD only ship pip et al for a single
> interpreter version.
> OpenBSD has a symbolic "python3" package that installs a specific
> version. Homebrew has a "python3" alias that chooses a specific Python
> interpreter version. MacPorts similarly has a symbolic "py-setuptools"
> package that will choose a specific interpreter version.
> 
> These are used as heuristics to determine a "de-facto" default for the
> ports collection platforms.
> 
> -
> 
> That's all for now. I will publish the script to the list later,
> though I have no intention of cleaning it up for inclusion in our
> tree. When I send it, bookmark the email if you'd like to try using
> this for other purposes or running it for yourself. Maybe I will throw
> it up on my personal GitLab in case it is useful to other subsystem
> maintainers in the future. The filtering code is a little messy, but
> it got the job done and should be reasonably straightforward to make
> sense of at a glance. It uses only the 'requests' library as a third
> party dependency.
> 
> Your humble Python sin-eater,
> --js
> 
> 
> 

Re: Python ecosystem versions overview

[John Snow]

[-- Attachment #1: Type: text/plain, Size: 7013 bytes --]

On Tue, Jul 8, 2025, 7:23 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 7/8/25 22:36, John Snow wrote:
> > centos_stream_9     3.9.23   21.3.1  53.0.0      3.4.3   BaseOS, CRB
>
> Ok, so the lowest version of Sphinx (3.4.3) is currently used for CentOS
> Stream 9.  It's supported for roughly 2 more years, until 12.0.
>

Yep. I am thinking however that because 3.9 is soon to be EOL this autumn,
it may become reasonable to start requiring newer Python interpreters for
this platform as well. They *are* available.

I won't do it without a reason, but I think this may be a reasonable policy
moving forward- If your platform is otherwise supported by our policy but
ships a version of Python from more than five years ago (aka is EOL
upstream), you *may* be required to install a newer, optional version (if
and only if one is reasonably available from official distro repositories.)

In general, this should have little to no impact except that isolated,
offline builds (a la rpmbuild) may fail to produce documentation unless
special considerations are taken for the build environment (namely, sphinx
needs to be loaded for the newer interpreter).

I think this is a reasonable compromise. If distributions want to package
bleeding edge QEMU with five-years-old dependencies, they can expect to
face *some* hurdles, and figuring out how to get sphinx as a builddep to
build an optional component is not entirely unreasonable.

TLDR - I pledge to support any platform covered by our promise for
building, but testing and documentation *requires* a non-EOL interpreter.
This should have little to no effect for developers or users building from
source or git, but has minor drawbacks for downstream maintainers of
enterprise distributions that may attempt to backport bleeding edge QEMU
versions.


> > opensuse_leap_15_6  3.6.15   20.0.2  44.1.1      2.3.1   updates/sle,
>
> We use the 3.11 runtime in the dockerfile, see
> tests/lcitool/mappings.yml.  That is a bare minimum install, so
> configure won't use the distro sphinx and instead use 5.3.0 from
> pythondeps.toml.
>

Yep, this tool was made to show the platform defaults only for now. Maybe
I'll add a "show first party backports" flag in the future, if anyone more
than just my own personal self would find that useful. (Speak up if so.)


> > main/oss
> > pkgsrc_current      3.12.11  25.1.1  80.9.0      8.2.3   ---
> > ubuntu_22_04        3.10.12  22.0.2  59.6.0      4.3.2
> > jammy-updates/main, jammy/universe, jammy/main
>
> This is the second oldest version of Sphinx.
>

With us until 26.04, in about 0.75 years. This seems like a reasonable new
minimum if we wanted to increase it, though that does artificially drop
support for RHEL9/CentOS stream building documentation from source under
rpmbuild.

(FWIW I probably can continue to support sphinx 3.x for a little while, the
code is gross but it does appear functional. The only thing we *need* to do
is bump the preferred version, I think. This support generally comes at the
expense of type checking support for the docs code, as it's so gross I
couldn't get it to work from 3.x to 8.x inclusive.)


> > ubuntu_24_04        3.12.3   24.0    68.1.2      7.2.6   noble/main,
> > noble/universe
> > ubuntu_24_10        3.12.7   24.2    74.1.2      7.4.7
> > oracular/main, oracular/universe
> > ubuntu_25_04        3.13.3   25.0    75.8.0      8.1.3   plucky/main,
> > plucky/universe
> >
> > (3) CentOS stream does not ship "sphinx" except via "CRB", which I
> > think may not be enabled by default.
>
> It's not, but it's intended to be enabled when developing against the
> Red Hat packages.  We enable it in the dockerfile:
>
>      dnf config-manager --set-enabled -y crb
>

Sounds good! I was just taking care to be diligent about which repositories
this tool compiled info from in order to give a very honest snapshot. I
made careful note of any "weird" ones that may or may not be considered
platform standards.


> > (4) OpenSUSE Leap 15.6 is egregiously old. 16.x is promised for later
> > this year, but we are past the promised "five year" support window for
> > this platform in some sense -- 15.0 released in 2018 -- so I believe
> > it can actually be ignored.
>
> As far as Python is concerned, OpenSUSE 15 doesn't cause trouble anyway,
> because we do not use the 3.6 interpreter and its very old distro packages.
>
> So that's two reasons to ignore OpenSUSE.
>

Yep, just formally stating that not only do we have a workaround, but we
may have run afoul of the five year window regardless.

Hopefully a non-issue once 16 ships.

(I am of course glad it works anyway!)

Just interesting to note that OpenSUSE would already have the same problems
CentOS 9 might in the near future: optional Python upgrade is available,
but distro-packaged Sphinx upgrade may not be.


> > (5) Ubuntu only ships pip in "universe", but also ships some Python
> > 3.x interpreter updates to that repository as well. I have filtered
> > this list to only use Universe for pip packages, leaving Python the
> > base version that ships with the platform in x/main or x-updates/main.
>
> Yes, fair enough.  Ubuntu 22.04 came out more recently than CentOS
> Stream 9, after all, and its base distribution is more up to date than
> CS9 with respect to the Python ecosystem.  Rust is where Ubuntu (both
> 22.04 and 24.04) is considerably less updated.
>
> Paolo
>
> > (6) "ports" collections (FreeBSD, NetBSD, OpenBSD/pkgsrc_current,
> > Homebrew and MacPorts) do not necessarily have the concept of a
> > platform default Python interpreter version, but other packages in the
> > collection can be used as a heuristic to determine which one is best
> > suited.
> >
> > For instance, FreeBSD and NetBSD only ship pip et al for a single
> > interpreter version.
> > OpenBSD has a symbolic "python3" package that installs a specific
> > version. Homebrew has a "python3" alias that chooses a specific Python
> > interpreter version. MacPorts similarly has a symbolic "py-setuptools"
> > package that will choose a specific interpreter version.
> >
> > These are used as heuristics to determine a "de-facto" default for the
> > ports collection platforms.
> >
> > -
> >
> > That's all for now. I will publish the script to the list later,
> > though I have no intention of cleaning it up for inclusion in our
> > tree. When I send it, bookmark the email if you'd like to try using
> > this for other purposes or running it for yourself. Maybe I will throw
> > it up on my personal GitLab in case it is useful to other subsystem
> > maintainers in the future. The filtering code is a little messy, but
> > it got the job done and should be reasonably straightforward to make
> > sense of at a glance. It uses only the 'requests' library as a third
> > party dependency.
> >
> > Your humble Python sin-eater,
> > --js
> >
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 9463 bytes --]

Re: Python ecosystem versions overview

[Markus Armbruster]

John Snow <jsnow@redhat.com> writes:

> On Tue, Jul 8, 2025, 7:23 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> On 7/8/25 22:36, John Snow wrote:
>> > centos_stream_9     3.9.23   21.3.1  53.0.0      3.4.3   BaseOS, CRB
>>
>> Ok, so the lowest version of Sphinx (3.4.3) is currently used for CentOS
>> Stream 9.  It's supported for roughly 2 more years, until 12.0.
>>
>
> Yep. I am thinking however that because 3.9 is soon to be EOL this autumn,
> it may become reasonable to start requiring newer Python interpreters for
> this platform as well. They *are* available.
>
> I won't do it without a reason, but I think this may be a reasonable policy
> moving forward- If your platform is otherwise supported by our policy but
> ships a version of Python from more than five years ago (aka is EOL
> upstream), you *may* be required to install a newer, optional version (if
> and only if one is reasonably available from official distro repositories.)
>
> In general, this should have little to no impact except that isolated,
> offline builds (a la rpmbuild) may fail to produce documentation unless
> special considerations are taken for the build environment (namely, sphinx
> needs to be loaded for the newer interpreter).
>
> I think this is a reasonable compromise. If distributions want to package
> bleeding edge QEMU with five-years-old dependencies, they can expect to
> face *some* hurdles, and figuring out how to get sphinx as a builddep to
> build an optional component is not entirely unreasonable.

I agree.

Moreover, I can't see why we should invest into making such packaging
easy without a shred of evidence for anyone actually doing it.

> TLDR - I pledge to support any platform covered by our promise for
> building, but testing and documentation *requires* a non-EOL interpreter.
> This should have little to no effect for developers or users building from
> source or git, but has minor drawbacks for downstream maintainers of
> enterprise distributions that may attempt to backport bleeding edge QEMU
> versions.
>
>
>> > opensuse_leap_15_6  3.6.15   20.0.2  44.1.1      2.3.1   updates/sle,
>>
>> We use the 3.11 runtime in the dockerfile, see
>> tests/lcitool/mappings.yml.  That is a bare minimum install, so
>> configure won't use the distro sphinx and instead use 5.3.0 from
>> pythondeps.toml.
>>
>
> Yep, this tool was made to show the platform defaults only for now. Maybe
> I'll add a "show first party backports" flag in the future, if anyone more
> than just my own personal self would find that useful. (Speak up if so.)
>
>
>> > main/oss
>> > pkgsrc_current      3.12.11  25.1.1  80.9.0      8.2.3   ---
>> > ubuntu_22_04        3.10.12  22.0.2  59.6.0      4.3.2
>> > jammy-updates/main, jammy/universe, jammy/main
>>
>> This is the second oldest version of Sphinx.
>>
>
> With us until 26.04, in about 0.75 years. This seems like a reasonable new
> minimum if we wanted to increase it, though that does artificially drop
> support for RHEL9/CentOS stream building documentation from source under
> rpmbuild.
>
> (FWIW I probably can continue to support sphinx 3.x for a little while, the
> code is gross but it does appear functional. The only thing we *need* to do
> is bump the preferred version, I think. This support generally comes at the
> expense of type checking support for the docs code, as it's so gross I
> couldn't get it to work from 3.x to 8.x inclusive.)

It's gross, it's functional, it's impressive in a "don't do this at
home, kids" way, and it comes with a big, red "John, help!"  button for
you to smash in case of trouble.  Because the few smart enough to be
able to maintain that code are almost certainly much too smart to be
willing to maintain that code.

[...]

Re: Python ecosystem versions overview

[John Snow]

Top-posting (Gasp!) to share a gitlab URL where this script is now located.

https://gitlab.com/jsnow/repology-dashboard#

GPL2.0-or-later, barely polished, a bit hacky. Have fun! This script
outputs more data than you've ever wanted to stdout, json and csv.
Suggestions/patches welcome if you find the script useful but clunkily
written (it is clunkily written.) The repo contains all of the sample
output in a data/ folder you can nose around if desired.

I currently have no appetite for trying to get this into qemu.git as a
maintainer scrichvrches nightmarespt, but maybe you do - in which
case, be my guest and change absolutely whatever you want to make it
happen, I do not care and have no pride on the matter. O:-)

--js

P.S. would it maybe be worth reproducing the summary table as-is in
our developer manual as something linked to from the platform policy
page? It will rot over time, but it's still potentially a quite useful
reference and I don't know where else to put it. I know we have a
wiki, but I think the wiki is not really a great source of information
for our project as *most* pages there are quite rotted.


On Tue, Jul 8, 2025 at 4:36 PM John Snow <jsnow@redhat.com> wrote:
>
> Hi, recently there was some discussion and debate over what versions
> of which things in the Python ecosystem we need to support with
> regards to our build platform promise. I don't address those issues in
> this mail at all. O:-)
>
> In researching that problem, I created a CLI script to automatically
> poll repology and several other sources (homebrew and macports APIs)
> to assemble a cohesive overview of the "Python ecosystem" across all
> of our target platforms. I felt this was necessary because it's often
> quite difficult to determine at a glance what is available as each
> platform has quite different ways of packaging, de/bundling, or
> factoring these tightly related projects.
>
> Here's the summary output:
>
> nago@fedora ~/s/repology-dashboard (devel)> python3 python_repology.py
> Fetching https://repology.org/api/v1/project/python
> Fetching https://repology.org/api/v1/project/python%3Asphinx
> Fetching https://repology.org/api/v1/project/python%3Asetuptools
> Fetching https://repology.org/api/v1/project/setuptools
> Fetching https://repology.org/api/v1/project/pip
> Fetching https://ports.macports.org/api/v1/ports/py-setuptools/
> MacPorts de-facto python version is python313. Results will be narrowed.
> FreeBSD de-facto python version is 311. Results will be narrowed.
> NetBSD de-facto python version is 312. Results will be narrowed.
> Fetching https://formulae.brew.sh/api/formula/python@3.13.json
> Homebrew de-facto python version is python@3.13. Results will be narrowed.
>
> ...
>
> ========
> overview
> ========
> distro              python3  pip     setuptools  sphinx  repos
> -------------------------------------------------------------------------------------------------------
> alpine_3_19         3.11.13  23.3.1  70.3.0      6.2.1   main,
> community
> alpine_3_20         3.12.11  24.0    70.3.0      7.2.6   main,
> community
> alpine_3_21         3.12.11  24.3.1  70.3.0      8.1.3   main,
> community
> alpine_3_22         3.12.11  25.1.1  80.9.0      8.2.3   main,
> community
> centos_stream_9     3.9.23   21.3.1  53.0.0      3.4.3   BaseOS, CRB
> centos_stream_10    3.12.11  23.3.2  69.0.3      7.2.6   BaseOS, CRB
> debian_12           3.11.2   23.0.1  66.1.1      5.3.0   bookworm/main
> fedora_40           3.12.10  23.3.2  69.0.3      7.2.6   updates,
> release
> fedora_41           3.13.5   24.2    69.2.0      7.3.7   updates,
> release
> fedora_42           3.13.5   24.3.1  74.1.3      8.1.3   updates,
> release
> freebsd             3.11.13  23.3.2  63.1.0      5.3.0   ---
> homebrew            3.13.5   ---     80.9.0      8.2.3   ---
> macports            3.13.5   25.1.1  78.1.1      8.2.3   ---
> openbsd             3.12.11  25.1.1  79.0.1      8.2.3   ---
> opensuse_leap_15_6  3.6.15   20.0.2  44.1.1      2.3.1   updates/sle,
> main/oss
> pkgsrc_current      3.12.11  25.1.1  80.9.0      8.2.3   ---
> ubuntu_22_04        3.10.12  22.0.2  59.6.0      4.3.2
> jammy-updates/main, jammy/universe, jammy/main
> ubuntu_24_04        3.12.3   24.0    68.1.2      7.2.6   noble/main,
> noble/universe
> ubuntu_24_10        3.12.7   24.2    74.1.2      7.4.7
> oracular/main, oracular/universe
> ubuntu_25_04        3.13.3   25.0    75.8.0      8.1.3   plucky/main,
> plucky/universe
>
> Some notes and observations:
>
> (1) Homebrew doesn't have a pip version listed because technically
> Homebrew does not ship pip; it's bundled directly with python. I did
> not find any reasonable mechanism to determine what that version is.
> However, as part of a "ports" style collection, it's usually bleeding
> edge and not likely to run afoul of "too old to reasonably support".
>
> (2) Alpine doesn't ship pip except via its "community" repo. I am
> unclear on if this is a repository enabled by default or not.
>
> (3) CentOS stream does not ship "sphinx" except via "CRB", which I
> think may not be enabled by default.
>
> (4) OpenSUSE Leap 15.6 is egregiously old. 16.x is promised for later
> this year, but we are past the promised "five year" support window for
> this platform in some sense -- 15.0 released in 2018 -- so I believe
> it can actually be ignored. Even though we still have a (working)
> dockerfile for it, and I see value in supporting SUSE in general,
> future python subsystem decisions may opt to exclude SUSE as a
> first-tier supported platform as per our policy. (It is also possible
> to pull in newer packages from different streams, but I was unable to
> investigate this in detail at this time.)
>
> (5) Ubuntu only ships pip in "universe", but also ships some Python
> 3.x interpreter updates to that repository as well. I have filtered
> this list to only use Universe for pip packages, leaving Python the
> base version that ships with the platform in x/main or x-updates/main.
>
> (6) "ports" collections (FreeBSD, NetBSD, OpenBSD/pkgsrc_current,
> Homebrew and MacPorts) do not necessarily have the concept of a
> platform default Python interpreter version, but other packages in the
> collection can be used as a heuristic to determine which one is best
> suited.
>
> For instance, FreeBSD and NetBSD only ship pip et al for a single
> interpreter version.
> OpenBSD has a symbolic "python3" package that installs a specific
> version. Homebrew has a "python3" alias that chooses a specific Python
> interpreter version. MacPorts similarly has a symbolic "py-setuptools"
> package that will choose a specific interpreter version.
>
> These are used as heuristics to determine a "de-facto" default for the
> ports collection platforms.
>
> -
>
> That's all for now. I will publish the script to the list later,
> though I have no intention of cleaning it up for inclusion in our
> tree. When I send it, bookmark the email if you'd like to try using
> this for other purposes or running it for yourself. Maybe I will throw
> it up on my personal GitLab in case it is useful to other subsystem
> maintainers in the future. The filtering code is a little messy, but
> it got the job done and should be reasonably straightforward to make
> sense of at a glance. It uses only the 'requests' library as a third
> party dependency.
>
> Your humble Python sin-eater,
> --js