Hello! One of the topics in the Python BoF in DebConf26 was about Python 3.15. I said that I had some time that I could dedicate to it, so this a bit of a progress report, a bit of a call for help, and a bit of following the Upgrade Procedure point 3 [2].
# Context Python 3.15 introduces a bunch of changes that make it interesting [4]. Probably the most interesting feature is the stabilization of abi3t, the free threaded (no gil) abi. Python extensions that use the Limited API can then be built to provide a free threaded extension. So far our packaging of python3.15 does not include a python3.15t or a libpython3.15t, we will need to add that, and adapt a part of our pybuild tooling so our packages can ship an abi3t extension. # Progress To tackle the migration, I've been rebuilding packages against Python 3.15rc1, using debusine [1]. By now, I've attempted to build around 3k packages (out of 7k involved in the whole migration). Of these, around 100 failed to build, and about 60 failed their tests. To aid with wrangling this huge amount of packages, I've put together a dashboard [3], that helps visualize the results and understand the state different packages are in. This is very much work in progress, I expect to improve the dashboard as I keep working on the migration. # RFH: Updating python3-defaults in experimental To simplify the work of people that want to test against 3.15 and 3.15t, it would be useful to have python3.15 listed as a supported version in python3-defaults in experimental. This is easy to do, just changing a variable in the package, but I don't feel comfortable doing this myself, as I'm not part of the cpython-team (given that I'm working on this migration, I am interested in being part of the team, but it's up to the team members to decide). In any case, if someone in the team has the time to do this change, please upload the package as it would make testing a lot easier. # RFH: Fixing packages As mentioned above, there are quite a few packages that are failing to build. I've been filing bugs with the python3.15 tag [5], and would appreciate some help both with maintainers applying the patches and with people helping find and patch bugs in other failing packages. As I make progress looking at the failures, I try to find commonalities, so I may be able to send bugs or patches to multiple packages that fail in a similar way. # Discussion point: How will we suport the free threaded interpreter? Up to now, we've been using dh-python relying on which (lib)?python3(.*)-dev are installed, and py3versions to list available versions and to check which one is the default. We now face a different challenge, as in order to build a package with free threaded support, the package needs to actually support it. So, we will have two different interpreter variants and some packages may support both while others may support only the regular one. We need to somehow modify our tooling to allow packages to declare thatthey support building against the no-gil variant.
- We could use something similar to XS-Python-Versions (like XS-Python-Variant) but this comes with some parsing challenges. - We could rely on having a build dependency python3t-dev and python3t-all-dev, for packages that support the no-gil variant. - We could add a parameter to py3version so that it also lists the no-gil variant as a separate version. This should make it easier for packages where we need to explicitly handle multiple python versions (not the best example but something like [6]) # Discussion point: support of abi3.abi3t packaging So far, our packaging practices (and policy) regarding packages that ship python extensions prefer to ship multiple .so versions, one for each supported python version. Upstream instead is working on making abi3 and abi3t stable so an extension built as .abi3.so can be used in any supported python3.12+ interpreter, while an abi3t.so could be used with any python3.15t+ interpreter. Using this approach would reduce the amount of rebuilds that we require to upgrade a python version, and also reduce the size of the binary packages. Projects like pyqt already use this approach, and I think that it's going to be adopted more and more upstream, so we may want to consider switching to this approach as the prefered form. Happy hacking, [1]: https://debusine.debian.net/debian/r-python-python3.15/ [2]: https://www.debian.org/doc/packaging-manuals/python-policy/#document-upgrade-procedure [3]: https://t.gnuservers.com.ar [4]: https://en.wikipedia.org/wiki/May_you_live_in_interesting_times [5]: https://bugs.debian.org/cgi-bin/[email protected]&tag=python3.15 [6]: https://salsa.debian.org/science-team/bornagain/-/merge_requests/2/diffs#8756c63497c8dc39f7773438edf53b220c773f67_20_22 -- "Whenever possible, steal code." -- Tom Duff Saludos /\/\ /\ >< `/
signature.asc
Description: PGP signature
