Hey folks,
We had a Python Team BoF at DC22 earlier today and I thought relaying
the notes we took in gobby here would be a good idea.
--
== python3.11 ==
python3.11 release has been delayed, from october 2022 to december 2022.
python3.12 is planned for october 2023.
Debian testing freeze for transitions is in January 2023, which is very
tight.
Do we want to try python3.11 in bookworm, or do we delay it for after
the freeze?
One problem we'll likely have, is upstream python libraries might not
have started playing with 3.11 already. It might be hard to try to use
beta versions right now to try and prepare the transition.
Once the default version in the archive has changed, it's hard to revert
to an older one.
Some packages like pandas and numba (and dart?) might need an exception
from the Release Team to allow us to upload versions more compatible
with 3.11 after the bookworm release.
For sure, this is a lot of work for me (zigo) on the OpenStack packages.
On each Python 3 release, this makes me fix lots of stuff. At the
moment, upstream OpenStack isn't even on Python 1.10 on its CI...
As a datapoint, Ruby always releases on Christmas, and the Ruby team has
never even attempted to push that as a default in the next Debian stable
release.
3.11 beta 4 is already in unstable, people can start trying to build
against it.
3.10 EOL is october 2026.
upstream is working on lots of speed optimizations. 3.11 has a bunch of
these that our users would appreciate.
3.11 as an extra supported version might work out, but it will create
subtle breakage for packages that happen not to be compatible with that
version, so we should avoid that in a stable release.
3.11 cannot be easily tested via an archive rebuild since there are
about 25 stages to a transition which build on top of one another.
Doko asked if it would be possible to have the Python releases 1 month
earlier, to which people replied: "Why doesn't Debian change their
release dates?". :(
== PEP 668 ==
https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/
https://peps.python.org/pep-0668/
We would like to have an directory reserved for distro-managed packages,
where pip should not be installing anything.
upstream pip seems to be keen on that, although there are currently no
issues in their bug report about it.
it would also be nice to have a python option to only use distro-managed
packages on the load path.
== pybuild improvements ==
getting the autopkgtest MR in would be great
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27
We need people to test this MR some more, although it seems fairly mature.
It might be a good idea to have a line in d/control to let us migrate
from the existing autopkgtests running unit tests to the new automated MR.
== lintian tags requests for the team ==
pollo will write you Python-related lintian tags. Ask him to.
* find packages that are building extensions only for the current Python
default version, instead of all the available python versions.
* warn packages still using distutils.version (removal in python 3.12)
It would be nice if lintian brush could help us migrate to pybuild-pyproject
- pollo can ping Jelmer.
== upstream cpython patches ==
Some work has been done, but some Debian patches still need to be
forwarded to python upstream
== where are we with python2rm? ==
pypy is still a blocker. A solution would be to bundle the python2
source code in it.
Other blockers
(https://release.debian.org/transitions/html/python2-rm.html):
python-defaults
python2.7
pam-python
python-stdlib-extensions
redland-bindings #938345 orphaned, key package
mozilla-devscripts (used for firefox extension building) #937085 key package
python-setuptools
python2-pip
six
== possible remote sprint? ==
a good time to have a remote sprint would be after adding python3.11 as
the new default (and thus creating new RC bugs). Therefore, this would
be between end of October up to early December.
== tracker.d.o dashboard ==
https://tracker.debian.org/teams/python-modules/
Would be great to have Salsa MRs on it
--
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
