[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ B ] [ C ] [ next ]

Debian Python Policy
Chapter 2 - Python Packaging

2.1 Versions

At any given time, the binary package python will represent the current default Debian Python version. The binary package python3 will represent the current Debian Python 3 version. As far as is reasonable, python and python3 should be treated as separate runtime systems with minimal interdependencies. In some cases, Python policy explicitly references Python helper programs such as python-support and python-central. None of these references apply to Python 3. It is a design goal to fully specify required interfaces and functions in policy for Python 3 and to avoid enshrining specific implementation details in policy. Except as noted, policy for Python 3 is the same as Python with the addition of the version number as needed to distinguish them.

The default Debian Python version should always be the latest stable upstream release that can be fully integrated in the distribution. There may be newer supported or unsupported versions included in the distribution if they are not fully integrated for a particular release.

Apart from the default version, legacy versions of Python or beta versions of future releases may be included as well in the distribution, as long as they are needed by other packages, or as long as it seems reasonable to provide them. (Note: For the scope of this document, Python versions are synonymous to feature releases, i.e. Python 2.7 and 2.7.1 are sub-minor versions of the same Python version 2.7, but Python 2.6 and 2.7 are indeed different versions.)

For any version, the main binary package must be called pythonX.Y.

The set of currently supported python versions can be found in /usr/share/python/debian_defaults, the set of currently supported python3 versions can be found in /usr/share/python3/debian_defaults. These files are in Python ConfigParser format and defines four variables in its DEFAULT section: default-version which is the current default Python runtime, supported-versions which is the set of runtimes currently supported and for which modules should be built and byte-compiled, old-versions which is the list of runtimes which might still be on the system but for which should not be built anymore, and unsupported-versions which is the list of runtimes which should not be supported at all, that is modules should not be built or byte-compiled for these. The supported interface to this file is /usr/bin/pyversions. The Python 3 interface is through /usr/bin/py3versions.

unsupported-versions is a superset of (includes) old-versions and the default-version is always in supported-versions.

Newer versions might also appear in unsupported-versions before being moved to supported-versions.

2.2 Main packages

For every Python version provided in the distribution, the binary package pythonX.Y shall provide a complete distribution for deployment of Python scripts and applications. The package must ensure that the binary /usr/bin/pythonX.Y is provided.

Installation of pythonX.Y shall provide the modules of the upstream Python distribution with some exceptions.

Excluded are modules that cannot be included for licensing reasons (for example the profile module), for dependency tracking purposes (for example the GPL-licensed gdbm module) or that should not be included for packaging reasons (for example the tk module which depends on Xorg). Some tools and files for the development of Python modules are split off in a separate binary package pythonX.Y-dev. Documentation will be provided separately as well.

At any time, the python binary package must ensure that /usr/bin/python is provided as a symlink to the current pythonX.Y executable. The python binary package must also depend on the appropriate pythonX.Y to ensure this runtime is installed.

The version of the python binary package must be greater than or equal to X.Y and smaller than X.Y+1.

Because upstream has started providing it, there will be a symlink for /usr/bin/python2 for Wheezy and later releases. See PEP-0394 for details. Packages must be careful to depend on a sufficient version of python if they make use of this symlink.

2.3 Minimal packages

For every Python version provided in the distribution, the binary package pythonX.Y-minimal might exist and should not be depended upon by other packages except the Python runtime packages themselves.

2.4 Python Interpreter

2.4.1 Interpreter Name

Python scripts depending on the default Python version (see Main packages, Section 2.2) or not depending on a specific Python version should use python (without a version) as the interpreter name.

Python scripts that only work with a specific Python version must explicitly use the versioned interpreter name (pythonX.Y).

2.4.2 Interpreter Location

The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y. This ensures that a Debian installation of python is used and all dependencies on additional python modules are met.

Maintainers should not override the Debian Python interpreter using /usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of python.

2.5 Module Path

By default, Python modules are searched in the directories listed in the PYTHONPATH environment variable and in the sys.path Python variable. Since python2.4 version 2.4.5-3, python2.5 version 2.5.2-7, python2.6 version 2.6.2-1, and in all python2.7 versions, sys.path does not include a /usr/lib/pythonXY.zip entry anymore. Directories with private Python modules must be absent from the sys.path. Public Python modules not handled by python-central or python-support must be installed in the system Python modules directory, /usr/lib/pythonX.Y/dist-packages for python2.6 and later, and /usr/lib/pythonX.Y/site-packages for python2.5 and earlier. Public Python 3 modules must be installed in /usr/lib/python3/dist-packages. Modules managed by python-support are installed in another directory which is added to the sys.path using the .pth mechanism. The .pth mechanism is documented in the Python documentation of the site module. A special directory is dedicated to public Python modules installed by the local administrator, /usr/lib/python3/dist-packages for all python3 versions, /usr/local/lib/python2.Y/dist-packages for python2.6 and later, and /usr/local/lib/python2.Y/site-packages for python2.5 and earlier. For a local installation by the administrator of python2.6 and later, a special directory is reserved to Python modules which should only be available to this Python, /usr/local/lib/python2.Y/site-packages (and /usr/local/lib/python3/site-packages for all python3 versions). Unfortunately, for python2.5 and earlier this directory is also visible to the system Python. Additional information on appending site-specific paths to the module search path is available in the official documentation of the site module.

When binary packages ship identical source code for multiple Python versions, for instance /usr/lib/python2.6/dist-packages/foo.py and /usr/lib/python2.5/site-packages/foo.py, these should point to a common file. Version specific directories for identical source code are not required for python3 and must not be used for this. Since python2.7 is the last python2 version and the only supported version in wheezy and later releases, a common location to share arch-independent files across Python versions is no longer needed. Historically the location for this was /usr/share/pyshared. For python2.7, use of /usr/lib/python2.7/dist-packages is sufficient. For python3, a special location is not required, use /usr/lib/python3/dist-packages

2.6 Hooks for updates to installed runtimes

The python binary package has special hooks to allow other packages to act upon updates to the installed runtimes. This mechanism is required to handle changes of the default Python runtime in some packages and to enable the Python packaging helpers. There are three supported hook types which come in the form of scripts which are invoked from the maintainer scripts of the Python runtime packages when specific installations, removals, or upgrades occur.

/usr/share/python/runtime.d/*.rtinstall: these are called when a runtime is installed or becomes supported. The first argument is "rtinstall", the second argument is the affected runtime (for example pythonX.Y) and the third and fourth argument are the old and new version of this packaged runtime if this runtime was already installed but unsupported.

/usr/share/python/runtime.d/*.rtremove: these are called when a runtime is removed or stops being supported. The first argument is "rtremove", and the second argument is the affected runtime (for example pythonX.Y).

/usr/share/python/runtime.d/*.rtupdate: these are called when the default runtime changes. The first argument is either "pre-rtupdate", called before changing the default runtime, or "rtupdate", called when changing the default runtime, or "post-rtupdate", called immediately afterwards. The second argument is the old default runtime (for example pythonX.Y), and the third argument is the new default runtime (for example pythonX.Z).

2.7 Documentation

Python documentation is split out in separate binary packages pythonX.Y-doc. The binary package python-doc will always provide the documentation for the default Debian Python version.

TODO: Policy for documentation of third party packages.