Debian Python FAQ

This is the FAQ of the debian-python@l.d.o mailing list. It is of particular interest to members of the Debian Python Modules Team. Please also look at Python for introductory info.

1. What are the projects and documentation available ?

If you're interested in help packaging Python itself, there's cpython-team but if you want to help with the Python modules or packaging a new one, you should look at Debian Python Modules Team project. Both groups discuss its activities in the same debian-python@l.d.o mailing list.

1.1. python-modules

The Debian Python Modules Team has its own policy, but keep in mind that they follow Debian Python Policy and of course Debian Policy too.

2. Multiple python versions support

Debian supports several versions of Python simultaneously. Some packages include modules only for the default version, while others provide modules for all available. These are generally all provided within a single binary package, although in the past multiple packages were sometimes used.

The general trend is to reduce that diversity and provide modules for all Python versions available within Debian using the following guidelines.

2.1. Build dependencies

For compiled modules you need to depend on python-all-dev, and python-all-dbg. For Python-only modules the sole python-all is sufficient if they use Python-based build system (like the very used distutils). A helper such as dh_python2 (or the deprecated python-support and python-central) will automagically manage bytecompilation.

3. Python 2 support

Debian 11 bullseye actually shipped with Python 2, but is probably the last release to do so. It does ship the /usr/bin/python binary through the python-is-python2 package. Almost *all* Python 2 packages, however, have been removed from bullseye. Out of the 2699 python-* packages (excluding -doc and -dbg packages) in Debian buster, 2616 were removed, and only therefore 90 left. That is 97% of the packages gone.

(Those numbers come from https://people.debian.org/~anarcat/python2-in-debian/ )

Debian 12 bookworm goes one step further and doesn't ship the python-is-python2 package **at all**. This implies that all Python scripts starting with #!/usr/bin/python will break unless (1) the python-is-python3 package is installed and (2) they are ported to Python 3 (obviously).

In general, we should consider Python 2 as unsupported and it will likely be completely removed from Debian 12 bookworm. One of the last blockers is that it is a build dependency of pypy, but it's possible cpython will just be bundled in that package instead.

4. Note on bytecompilation for pure Python modules

As the helpers manage late-bytecompilation, no .pyc/.pyo files shall be shipped in your package. You do no need to spend build time for generating them. With distutils use the "--no-compile -O0" options; dh and the python CDBS classes know how to handle this. Beware some upstream sources that contain a setup.cfg which override your build options (see 360848), then you will have to patch it. In all cases, dh_python2 or python-support will remove those files if they are generated.

4.1. What are dh_python2 and dh_python3?

dh_python{2,3} are the python helpers included in the python package since 2.6.6-3.

dh_python2 differs from python-support, in including the per-python-version symlink farm within the binary package, only requiring byte-compilation at install time. Packages using dh_python2 with public modules must be rebuilt when Debian changes the supported Python versions (this should never happen after 2.7).

They can also guess dependencies from requires.txt, for setuptools/distutils packages.

Instructions for transitioning to dh_python2 from python-support and python-central.

See dh_python2(1) or dh_python3(1) for more details.

4.2. What is python-support?

Python-support is a (now removed) tool to handle byte-compilation of python modules when there are several python versions installed on the system.

4.3. What is python-central?

Python-central is a (now removed) package that contains some helper scripts for building and installing python modules independent of the current installed Python version.

4.4. Should I use dh_pythonX, python-support or python-central?

dh_python2 is recommended for new Python 2 packages. dh_python3 is the only helper for Python3. python-support and python-central are deprecated.

Some statistics (the number of packages using each method - lower number is contrib), as of 2014-04-22:

~$ build-rdeps dh-python | grep total
Found a total of 283 reverse build-depend(s) for dh-python.
Found a total of 2 reverse build-depend(s) for dh-python.
~$ build-rdeps python-support | grep total
Found a total of 4 reverse build-depend(s) for python-support.
Found a total of 585 reverse build-depend(s) for python-support.

NB! Only python-support numbers are accurate, as other packages may build-depend indirectly on dh-python (for python3) or not use it at all (for python2)

5. Python eggs

5.1. What are Python eggs?

http://peak.telecommunity.com/DevCenter/PythonEggs

5.2. How should we package Python eggs?

We don't want to provide ".egg" files within the .deb. However we want to make the "egg meta-information" available so that users can use eggs if they so wish. Python >= 2.5 does that by default in distutils. For setuptools based setup.py you need to pass the option "--single-version-externally-managed" to the "setup.py install" call.

5.2.1. with dh_python2

This bug report provides relevant information:

5.2.2. with CDBS and setuptools

Packages relying on CDBS and setuptools can do that this way:

# Install egg-info directories
DEB_PYTHON_INSTALL_ARGS_ALL += --single-version-externally-managed

6. Package naming

For binary packages of Python libraries, the Python Library Style Guide has some answers. For source package names, there is no consensus on whether they should be "foo" for a package named "foo" on the Python package index, or "python-foo".


CategoryPermalink