F41 Change Proposal: Python 3.13 (System-Wide)

Project Discussion Change Proposals
,
1

Python 3.13

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

:link: Summary

Update the Python stack in Fedora from Python 3.12 to Python 3.13, the newest major release of the Python programming language.

:link: Owner

:link: Detailed Description

We would like to upgrade Python to 3.13 in Fedora 41 thus we are proposing this plan early.

See the upstream notes at What’s new in 3.13.

:link: Important dates and plan

  • 2023-05-22: Python 3.13 development begins
  • 2023-10-13: Python 3.13.0 alpha 1
    • Package it as python3.13 for testing purposes
    • Start the bootstrap procedure in Copr
    • Do a mass rebuild against every future release in Copr
  • 2023-11-21: Python 3.13.0 alpha 2
  • 2023-12-19: Python 3.13.0 alpha 3
  • 2024-01-16: Python 3.13.0 alpha 4
  • 2024-02-06: Branch Fedora 40, Rawhide becomes future Fedora 41
    • The earliest point when we can start rebuilding in Koji side-tag
  • 2024-02-13: Python 3.13.0 alpha 5
  • 2024-03-12: Python 3.13.0 alpha 6
  • 2024-04-09: Python 3.13.0 alpha 7
  • 2024-05-07: Python 3.13.0 beta 1
    • No new features beyond this point
  • 2024-05-28: Python 3.13.0 beta 2
    • The ideal point when we can start rebuilding in Koji
  • 2024-06-04: Expected side tag-merge (optimistic)
  • 2024-06-18: Python 3.13.0 beta 3
  • 2024-06-25: Expected side tag-merge (realistic)
  • 2024-07-15: Expected side tag-merge (pessimistic)
  • 2024-07-16: Python 3.13.0 beta 4
  • 2024-07-17: Fedora 41 Mass Rebuild
    • The mass rebuild happens with the fourth or third beta. We might need to rebuild Python packages later in exceptional case.
    • If the Koji side-tag is not merged yet at this point, we defer the change to Fedora 42.
  • 2024-07-30: Python 3.13.0 candidate 1
    • This serves as “final” for our purposes.
  • 2024-08-06: Branch Fedora 41, Rawhide becomes future Fedora 42
  • 2024-08-06: Fedora 41 Change Checkpoint: Completion deadline (testable)
  • 2024-08-20: Fedora Beta Freeze
    • If rebuild with 3.13.0rc1 is needed, we should strive to do it before the freeze - there is a window of 3 weeks.
  • 2024-09-03: Python 3.13.0 candidate 2
  • 2024-09-10: Fedora 41 Beta Release (Preferred Target)
    • Beta will likely be released with 3.13.0rc1.
  • 2024-09-17: Fedora 41 Beta Target date #1
  • 2024-10-01: Python 3.13.0 final
  • 2024-10-01: Fedora 39 Final Freeze
    • We’ll update to 3.13.0 final using a freeze exception.
  • 2024-10-15: Fedora 39 Preferred Final Target date
  • 2024-10-22: Fedora 39 Final Target date #1

(From Python 3.13 Release Schedule and Fedora 41 Release Schedule.)

The schedule might appear somewhat tight for Fedora 41, but Python’s annual release cycle was adapted for Fedora and this worked fine since Python 3.9 and Fedora 33. It is now common that Python is upgraded on a similar schedule in every odd-numbered Fedora release.

Note that upstream’s “release candidates” are frozen except for blocker bugs. Since we can and will backport blocker fixes between Fedora and upstream, we essentially treat the Release Candidate as the final release.

:link: Benefit to Fedora

Fedora aims to showcase the latest in free and open-source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3.13.

There’s also a benefit to the larger Python ecosystem: by building Fedora’s packages against 3.13 while it’s still in development, we can catch critical bugs before the final 3.13.0 release.

:link: Scope

We will coordinate the work in a side tag and merge when ready.

  • Proposal owners:

    1. Introduce python3.13 for all Fedoras
    2. Prepare stuff in Copr as explained in description.
    3. Update python-rpm-macros so python3.13 builds python3
    4. Build python3.13 as the main Python
    5. Mass rebuild all the packages that runtime require python(abi) = 3.12 and/or libpython3.12.so.1.0 (~4000 known packages in October 2023)
    6. Build python3.13 as a non-main Python

  • Other developers: Maintainers of packages that fail to rebuild during the rebuilds will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with the respective upstreams first and/or applying downstream patches. Also, the package maintainers should have a look at: Porting to Python 3.13. The python-maint team will be available to help with fixing issues.

  • Release engineering: #11728

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives: N/A

:link: Upgrade/compatibility impact

All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.12 is forward compatible with Python 3.13.

:link: How To Test

Interested testers do not need special hardware. If you have a favourite Python 3 script, module, or application, please test it with Python 3.13 and verify that it still works as you would expect. If the application you are testing does not require any other modules, you can test it using python3.13 even before this change is implemented, in Fedora 37, 38, 39 or 40.

In case your application requires other modules, or if you are testing an rpm package, it is necessary to install the 3.13 version of the python3 rpm. Right now that rpm is available in copr, along with all other python packages that build successfully with python 3.13. See @python/python3.13 Copr for detailed instructions on how to enable Python 3.13 copr for mock.

Once the change is in place, test if your favorite Python apps are working as they were before. File bugs if they don’t.

:link: User Experience

Regular distro users shouldn’t notice any change in system behaviour other than the Python 3 interpreter will be in version 3.13.

:link: Dependencies

4400+ packages depend on Python 3 and ~4000 packages need rebuilding when Python is upgraded. See scope section.

:link: Contingency Plan

  • Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.12 version (never needed before)
  • Contingency deadline: beta freeze
  • Blocks release? Yes, we’d like to block Fedora 41 release on at least 3.13.0rc1

:link: Documentation

Python 3.13 Release Schedule

What’s new in 3.13

Porting to Python 3.13

:link: Release Notes

2

Would it be possible to file bugs earlier then at 3.12? I think they
where filed as FTI after the side tag has been merged.

I am not sure how much work it would be to already file them before the
mass-rebuild, based on the copr state? Beta 1 would be my preferred
point. If there are no new features planed, I would expect further
breakage is unlikely, and it would give more time to help fix issues in
the package and it’s dependencies before it breaks rawhide.

Thanks for working on this,
David

3

I have already seen and handled a few bugs for 3.13, so they are being filed. I think this was the case for 3.12 as well. But a package is not built in the COPR unless all of its dependencies build successfully, so if a package continues to FTBFS on Python 3.13 until the side tag is merged, everything that depends on it will then be surprised by an FTI bug. I agree that it would be nice to have a little better and earlier insight into how broken my packages’ dependencies might be, although I’m not sure what is the best way to accomplish that.

4

Ah, thanks. That explains it then. I think I had always missing
dependencies, so I was surprised by FTI bugs.

Having bugs filed for missing dependencies would be great :slight_smile:

It would be great to include the dependency tree, but I would also be
happy with having a “Some dependency is FTBFS” would already be a start.
I assume that should be easy enough?

5

It is technically possible to file “your package will fail to install once we upgrade to Python 3.13 because it is now impossible to rebuild it due to unsatisfiable build dependencies” or “your package will fail to install once we upgrade to Python 3.13 because some of the runtime dependencies were not yet rebuilt”.

However, I see a big challenge with this approach:

  • If we do that early, we will have hundreds of bugzillas that will eventually fix themselves – some packagers will consider that noisy.
  • If we do it too late, we will not gain anything compared to the status quo.

If you get this bugzilla at beta 1, it would be just a couple weeks heads up. Is it worth it?

Surely, there must be a better way to signalize what packages cannot be rebuilt yet, than bugzillas. What about a status page you can occasionally check?

6

For example, currently, 1587 packages have not yet been successfully built in our Copr.

Out of those, only 10% have been attempted, the rest are waiting.

To get the list of packages, you can e.g.:

# all the Python 3.12 packages from rawhide
repoquery --repo=koji      --source --whatrequires 'libpython3.12.so.1.0()(64bit)' --whatrequires 'python(abi) = 3.12' --whatrequires 'python3.12dist(*)' | pkgname | env LANG=en_US.utf-8 sort | uniq > python312.pkgs

# all the Python 3.13 packages from copr (successful at least once)
repoquery --repo=python313 --source --whatrequires 'libpython3.13.so.1.0()(64bit)' --whatrequires 'python(abi) = 3.13' --whatrequires 'python3.13dist(*)' | pkgname | env LANG=en_US.utf-8 sort | uniq > python313.pkgs

# the 1587 packages not yet built in copr (failed + waiting)
env LANG=en_US.utf-8 comm -23 python312.pkgs python313.pkgs | grep -E -v '^(python3\.12)$' > todo.pkgs

# all packages (even failing) from copr
copr monitor @python/python3.13 --output-format text-row --fields name | env LANG=en_US.utf-8 sort > copr.pkgs

# waiting packages
env LANG=en_US.utf-8 comm -23 todo.pkgs copr.pkgs > waiting.pkgs
7

Hello,
I grabbed Miro’s queries and prototyped a simple status page for the ongoing rebuild: Fedora: Python 3.13 rebuild status page
It should get refreshed every night.
I’m thinking of adding links to the package in the Copr and Bugzillas.
The dependency tree (“what my package is blocked on?”) is trickier.

Feel free to check this out. I’ll appreciate feedback on whether it’s useful for you and what other information might increase your visibility into the process.

2 Likes
8

Wow, this is awesome

I wanted to mention that a packages-per-user page would be great, but
then I scrolled a bit further - and found it is already there :heart:

Thanks! I think adding a link to copr and the wiki might be useful - I
am already happy :slight_smile:

1 Like
9

And that is why we have an awesome community :heart_eyes:

10

This change proposal has now been submitted to FESCo with ticket #3111 for voting.

To find out more, please visit our Changes Policy documentation.

11

Just in case others ran into this, too: 3.13.0a1 removed a lot of functions from the C API as part of an experiment which will be partially reverted in alpha2. So here’s hoping this will unbreak a few packages (e.g. gdb).

12

Closing change proposals for F40. The ship has sailed. Of course we can still discuss if needed, but please open new topics for that.