Python 2 / PyPy removal help page

Announcement: https://lists.debian.org/debian-python/2019/07/msg00080.html

Transition: https://release.debian.org/transitions/html/python2-rm.html

Fedora: https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

Python 2 Countdown: https://pythonclock.org/

Common mistakes made when removing Python2 packages

Here are some issues seen for ongoing removal of Python2 packages:

Removing a python-foo package without checking for its reverse dependencies first. The py2removal bugs even show you that kind of information.
Forgetting to adjust autopkg tests:
- Not removing autopkg tests for python2, when the python-foo package is removed.
- Not changing the interpreter name from python to python2 in autopkg tests, when still keeping the Python2 package.
Not renaming python-foo to python3-foo, but building it with Python3.
Forgetting to instruct python3-foo to install /usr/bin/foo when python2-foo previously provided this interface.

Check list

Quick list of things to do while removing Python / ?PyPy binary package:

port upstream package to python3 (or file upstream bug): make sure package doesn't call python at build- or compile time (as there won't be a python package and no python command in bullseye, only python3.)
check for reverse dependencies (including build-depends)
- if there are any, you cannot remove it yet!
- if you decide to prepare the removal now and upload it later, post a message stating this to the py2removal bug, to avoid duplication of work. (However, for typical packages, the removal process is simple enough that this is unnecessary.)
remove python-foo and pypy-foo binary packages from debian/control
remove python-* Build-Depends from debian/control
if python-foo installed a /usr/bin/foo, then python3-foo must now begin installing one
remove any Python 2 use (e.g. --with python2) or python-foo / pypy-foo references from debian/rules
remove python-foo and pypy-foo autopkgtests (debian/tests/*)
if documentation was in python-foo - move it to python3-foo or python-foo-doc
- the contents of python-foo-doc will automatically move from /usr/share/doc/python-foo to /usr/share/doc/python-foo-doc - update any links to it, remembering to use symlink_to_dir when overwriting a link with a real directory
- do not remove python-foo-doc
- do not rename it to python3-foo-doc
check/remove debian/python-foo.* and pypy-foo.* files
mention Python 2 / ?PyPy removal in debian/changelog
build the source package
test it
upload it to unstable
reassign py2removal bug to ftp.debian.org pseudo packagenot any more

How to check for reverse dependencies

For a quick initial check / if you're looking for a package to work on, see http://sandrotosi.me/debian/py2removal/index.html: look for binary (not source) packages with 0 in the rdeps column.

To search for all runtime Depends/Recommends, and all mentions in the Sources index (Build-Depends*, Testsuite-Triggers, and the package itself):

Here python-$module is a binary package name.

grep-dctrl -w -F Pre-Depends,Depends,Recommends -s Package "python-$module" /var/lib/apt/lists/*_debian_dists_{unstable,sid}_main_binary-amd64_Packages 
grep-dctrl -w -s Package "python-$module" /var/lib/apt/lists/*_debian_dists_{unstable,sid}_main_source_Sources

Outputs:

only this package's name => ready to be removed
other package(s) => not ready yet
nothing => package doesn't exist (either it's already been removed, or you mis-spelt it)

The alternative of "apt-cache rdepends python-$module ; reverse-depends -b python-$module" (ubuntu-dev-tools package) can be slow and does not find autopkgtest depends.

usertags (debian-python@lists.debian.org)

PLEASE, when changing user tags, please CC the bug report, because it's non-obvious who is changing a user tag by reading the bug report.

Every package should be tagged with:

py2removal - all packages affected by Python 2 / ?PyPy removal

Add more tags for better classifications:

py2leaf - leaf package ready to be removed, i.e. without (build-)dependencies
- (including Recommends) in Debian main,
py3available - Python 3 support is available upstream, package needs an
- update in Debian,
py3noport - there's no upstream support for Python 3, needs a port done by us
- or package will be removed,
py2keep - package that should not be removed for now (popcon >1000 by
- default). Please don't add this usertag without discussing it on the mailing list first,
py2rm - packages that we will remove from Debian due to low popcon, etc.
- - all packages with popcon <300 will get this one by default, but it can be removed

FAQ

My package is affected only because it uses python-sphinx to generate documentation, what should I do?

just replace it with python3-sphinx, and in debian/rules, you can invoke Sphinx this way (the team do not recommand using the 'sphinx-build' command):

python3 -m sphinx

I hear there will still be a Python 2 interpreter in bullseye, can I use that in my package?

No you can't. From #975014:

Debian Bullseye includes a version of Python 2.7 (and a short list of
related packages like setuptools still built Python 2 packages). However, these
are only included for building a few applications which still require
Python 2 as part of their build process. Python 2 is not supported for
running applications and there won't be any security updates for Python
2 in Bullseye.

Discussions/Proposals

>  - bumping lintian info to warn, warn to error, ask ftp-master
>    to autoreject packages for some errors?

Likely to get pushback from ftp-master; notwithstanding the problems and advantages of removing Python2, autorejects should be for really rather severe issues IMHO.

Python2Removal