Bug 2418374

So this is in fact correct, no 3rd prarty Python modules/packages are available for versions other than the main. We don't have the human power to maintain several separate Python stacks packaged as RPM packages in Fedora.

However, if you want pip, you have several options. See https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html

Alternativelly, running `python3.13 -m ensurepip --user` is also supported:

$ python3.13 -m ensurepip --user
$ python3.13 -m pip --version
pip 25.2 from /home/.../.local/lib/python3.13/site-packages/pip (python 3.13)
$ python3.13 -m pip install --user yocto
...

I tried building python-setuptools from here: https://koji.fedoraproject.org/koji/buildinfo?buildID=2819549

$ sudo dnf install python3.13-devel
$ rpmbuild --rebuild --define='python3_pkgversion 3.13' --with bootstrap python-setuptools-78.1.1-15.fc43.src.rpm

which resulted in a parallel installable module package:

python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch.rpm

The resulting rpm cannot be installed:

$ sudo dnf install python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch.rpm 
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem: conflicting requests
  - nothing provides python(abi) = 3.13 needed by python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch from @commandline
You can try to add to command line:
  --skip-broken to skip uninstallable packages

Why doesn't the python3.13 package provide "python(abi) = 3.13"?

The newly built package may be forcibly installed:

$ sudo rpm -ivh --nodeps python3.13-setuptools-78.1.1-15.fc43~bootstrap.noarch.rpm 

Then it allows importing pieces provided by this module:

$ python3.13
Python 3.13.9 (main, Oct 14 2025, 00:00:00) [GCC 15.2.1 20250924 (Red Hat 15.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils
>>> 

When it's installed, the same package may be rebuilt without "--with bootstrap".
The resulting package needs a few more module packages to be built and installed.

If package builds are automated in koji (it isn't?), then it's simply a matter of adding --define='python3_pkgversion 3.nn' to the build matrix for the supported Python major versions.

But thanks, I will also try your suggestions.

> Why doesn't the python3.13 package provide "python(abi) = 3.13"?

To prevent Fedora packagers from accidentally building 3rd-party Python modules against it until such a solution is supported (currently, it is not).

> If package builds are automated in koji (it isn't?), then it's simply a matter of adding --define='python3_pkgversion 3.nn' to the build matrix for the supported Python major versions.

It's not that simple; we cannot add macro definitions to a build matrix and build multiple packages out of one source. Fedora packages don't work that way. There was modularity, which kinda promised to deliver this feature, but ultimately failed and was retired from Fedora: https://fedoraproject.org/wiki/Changes/RetireModularity

I see that this might look simple, but it isn't. Supporting multiple builds of multiple packages for multiple Pythons requires volunteers to drive that effort.

Yeah, this is really not something to discuss in a ticket. In the current scheme of things, having modules packaged for multiple python versions is not going to happen. Nor would it even be particularly desirable, considering how Fedora works. Feel free to open a discussion on the devel list, but I think that trying to change status quo would require finding a bunch of new people to spend time on this.

(In reply to Miro Hrončok from comment #1)
> So this is in fact correct, no 3rd prarty Python modules/packages are
> available for versions other than the main. We don't have the human power to
> maintain several separate Python stacks packaged as RPM packages in Fedora.
> 
> However, if you want pip, you have several options. See
> https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.
> html
> 
> Alternativelly, running `python3.13 -m ensurepip --user` is also supported:
> 
> $ python3.13 -m ensurepip --user
> $ python3.13 -m pip --version
> pip 25.2 from /home/.../.local/lib/python3.13/site-packages/pip (python 3.13)
> $ python3.13 -m pip install --user yocto
> ...

Just to document the solution if someone else needs to fix the same issue.

I tried your second suggestion together with a local PATH override
in my start script for bitbake so the "#!/usr/bin/env python3" shebang
finds an appropriate python3 version. Something like
https://serverfault.com/questions/579956/alias-doesnt-work-in-script-with-usr-bin-env-php

That worked for me now on F43 for an old Yocto 3.4 based build from 2021
with using Python 3.12 plus the necessary GCC 15 fix backports for a
handful of Yocto recipes that were already in place because of a previous
attempt on F42.