Yeah, the extra runtimes in a Linux environment are almost entirely fodder for tox
& nox
running test suites and other commands in multiple environments, developers locking specific target Python versions for general development activities, and tools like pipx
& uv tool
being able to upgrade the Python environments they manage independent of the timing of the OS updating the main system Python package. The fact everything above the Python runtime layer needs to be managed with Python level tooling is a feature for this use case rather than being a problem.
(edit: switched example to python3.11, as I forgot the mechanism for declaring the weak dependencies changed to something easier to maintain for the 3.11 release. For anyone unfamiliar with weak dependency declarations in Linux systems, see Weak Dependencies Policy :: Fedora Docs)
Using python3.11
in Fedora 40 as an example, only the other components built from the same SRPM have a hard dependency on the binary RPM containing the CPython CLI:
~$ sudo dnf repoquery --whatrequires python3.11 2>/dev/null | grep '3.11.9.*x86_64'
python3.11-debug-0:3.11.9-6.fc40.x86_64
python3.11-devel-0:3.11.9-6.fc40.x86_64
python3.11-idle-0:3.11.9-6.fc40.x86_64
python3.11-test-0:3.11.9-6.fc40.x86_64
python3.11-tkinter-0:3.11.9-6.fc40.x86_64
And only the Python 3.11 shared libraries directly recommend it:
~$ sudo dnf repoquery --whatrecommends python3.11 2>/dev/null --installed
python3.11-libs-0:3.11.9-2.fc40.x86_64
However, dnf install tox
still defaults to setting up a machine to run against every Python environment that Fedora supports, either because the tox
package recommends the runtime:
~$ sudo dnf repoquery --recommends tox 2>/dev/null
pypy2-devel
pypy3-devel
python2-devel
python2.7
python3-devel
python3.10
python3.6
python3.7
python3.8
python3.9
or because the runtimeās devel
package indicates that it supplements tox
(this declaration is in the devel
packages so that it also installs the C/C++ header files needed to build binary extensions from source):
~$ sudo dnf repoquery --whatsupplements tox 2>/dev/null --installed
pypy3.10-devel-0:7.3.15-2.3.10.fc40.x86_64
pypy3.9-devel-0:7.3.16-1.3.9.fc40.x86_64
python3-devel-0:3.12.4-1.fc40.x86_64
python3.10-devel-0:3.10.14-2.fc40.x86_64
python3.11-devel-0:3.11.9-2.fc40.x86_64
python3.13-devel-0:3.13.0~rc1-2.fc40.x86_64
Itās that developer experience of ātox
just works for Python cross-version testingā` that is hard to replicate outside the main repositories for a distribution (while 3rd party repositories and custom Python builds or downloads can make this kind of cross-version testing setup possible, only the main distro project can truly make it easy).
(FWIW, you can put me in the camp of folks that believe the level of demand for pre-built Linux binaries would be much lower if tox
worked nicely on Debian by default. Iām generally in favour of python.org offering something comparable to the python-build-standalone
builds, since there are some genuine use cases for that, but I see it as a workaround for the Debian āparallel Python installation for cross-version compatibility testingā developer UX issue, rather than a genuine fix for it. Most notably, the standalone binary approach means that each runtime bundles its own copy of OpenSSL instead of using the common system provided shared library)
@hroncok I noticed that tox
isnāt currently recommending python3.11
while writing the above illustrative commands, so I posted a BZ for that (Not a bug, the way the weak dependencies are declared just changed as per @barry-scottās post below)