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 <js...@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/pyt...@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
