= Goals for the DC22 Python Team BoF =

== 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.

It would be nice if lintian brush could help us migrate to pybuild-pyproject
	- pollo can ping Jelmer.

* warn packages still using distutils.version (removal in python 3.12)

== 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). Therefor, 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