JezK

Edit File: ch-python.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

<html>

<head>

<title>Debian Python Policy - Python Packaging</title>

</head>

<body>

[ <a href="ch-python3.html">previous</a> ]
[ <a href="index.html#contents">Contents</a> ]
[ <a href="ch-python3.html">1</a> ]
[ 2 ]
[ <a href="ch-module_packages.html">3</a> ]
[ <a href="ch-programs.html">4</a> ]
[ <a href="ch-embed.html">5</a> ]
[ <a href="ch-other.html">6</a> ]
[ <a href="ap-build_dependencies.html">A</a> ]
[ <a href="ap-packaging_tools.html">B</a> ]
[ <a href="ap-upgrade.html">C</a> ]
[ <a href="ch-module_packages.html">next</a> ]

<hr>

<h1>
Debian Python Policy
 Chapter 2 - Python Packaging
</h1>

<hr>

<h2 id="s-versions">2.1 Versions</h2>

At any given time, the binary package <code>python3</code> will represent the
current default Debian Python 3 version; the binary package <code>python</code>
will represent the current default Debian Python 2 version. As far as is
reasonable, Python 3 and Python 2 should be treated as separate runtime systems
with minimal interdependencies.

In some cases, Python policy explicitly references Python helper tools. For
Debian Stretch, the <code>dh-python</code> package provides the only such
tools; earlier helpers have been removed from Debian.

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 2 is the same as Python 3 with the
exception of the different major version number as needed to distinguish them.

The default Debian Python version, for each of Python 3 and Python 2, should
always be the latest stable upstream version that can be fully integrated in
Debian.

There may be newer supported or unsupported versions included in Debian if they
are not fully integrated for a particular release.

Apart from the default version, legacy versions of Python or beta releases of
future upstream versions may be included as well in Debian, 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, a Python version is synonymous with all
micro versions within that minor version. e.g. Python 3.5.0 and 3.5.1 are
micro versions of the same Python version 3.5, but Python 3.4 and 3.5 are
indeed different versions.

For any version, the main binary package must be called
<code>python<var>X</var>.<var>Y</var></code>.

The set of currently supported Python 3 versions can be found in
<code>/usr/share/python3/debian_defaults</code>; the supported interface to
this information is through <code>/usr/bin/py3versions</code>. The set of
currently supported Python 2 versions can be found in
<code>/usr/share/python/debian_defaults</code>; the supported interface to this
information is <code>/usr/bin/pyversions</code>.

These files are in Python <samp>configparser</samp> format. They define (in
the <samp>DEFAULT</samp> section) the following options:

<ul>
<li>

<samp>default-version</samp>: The name of the interpreter for the current
default Debian Python.

</li>
</ul>
<ul>
<li>

<samp>supported-versions</samp>: The set of interpreter names currently
supported and for which modules should be built and byte-compiled. This
includes <samp>default-version</samp>.

</li>
</ul>
<ul>
<li>

<samp>old-versions</samp>: The set of interpreter names which might still be on
the system but for which modules should not be built.

</li>
</ul>
<ul>
<li>

<samp>unsupported-versions</samp>: The set of interpreter names which should
not be supported at all, that is modules should not be built or byte-compiled
for these. This includes (is a superset of) <samp>old-versions</samp>.

</li>
</ul>

Newer versions might also appear in <samp>unsupported-versions</samp> before
being moved to <samp>supported-versions</samp>.

<hr>

<h2 id="s-base">2.2 Main packages</h2>

For every Python version provided in Debian, the binary package
<code>python<var>X</var>.<var>Y</var></code> shall provide a complete
distribution for deployment of Python scripts and applications. The
package must ensure that the binary
<code>/usr/bin/python<var>X</var>.<var>Y</var></code> is provided.

Installation of <code>python<var>X</var>.<var>Y</var></code> 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 <samp>profile</samp> module), for dependency tracking purposes (for example
the GPL-licensed <samp>gdbm</samp> module), or that should not be included for
packaging reasons (for example the <samp>tk</samp> module which depends on
Xorg).

Some tools and files for the development of Python modules are split
off in a separate binary package
<code>python<var>X</var>.<var>Y</var>-dev</code>.

Documentation will be provided separately as well.

At any time, the <code>python3</code> binary package must ensure that
<code>/usr/bin/python3</code> is provided, as a symlink to the current
<code>python3.<var>Y</var></code> executable. The package must depend on the
<code>python3.<var>Y</var></code> package that installs the executable.

The version of the <code>python3</code> package must be greater than or equal
to 3.<var>Y</var> and lower than 3.<var>Y+1</var>.

At any time, the <code>python</code> binary package must ensure that
<code>/usr/bin/python2</code> is provided, as a symlink to the current
<code>python2.<var>Y</var></code> executable. The package must depend on the
<code>python2.<var>Y</var></code> package that installs the executable.

The version of the <code>python</code> package must be greater than or equal to
2.<var>Y</var> and lower than 2.<var>Y+1</var>.

The <code>python</code> binary package must also ensure that
<code>/usr/bin/python</code> is provided, as a symlink to the current
<code>python2.<var>Y</var></code> executable. See <code><a
href="https://www.python.org/dev/peps/pep-0394/">PEP 394</a></code> for
details.

<hr>

<h2 id="s-minimal">2.3 Minimal packages</h2>

For every Python version provided in Debian, the binary package
<code>python<var>X</var>.<var>Y</var>-minimal</code> might exist and should not
be depended upon by other packages except the Python runtime packages
themselves.

<hr>

<h2 id="s-interpreter">2.4 Python Interpreter</h2>

<hr>

<h3 id="s-interpreter_name">2.4.1 Interpreter Name</h3>

The different Python major versions require different interpreters (see <a
href="#s-base">Main packages, Section 2.2</a>).

Python scripts that require the default Python 3 version should specify
<code>python3</code> as the interpreter name.

Python scripts that require the default Python 2 version should specify
<code>python2</code> as the interpreter name.

Python scripts may specify <code>python</code> as the interpreter name only if
they do not require any particular version of Python. (Note: this means any
python2 version)

Python scripts that only work with a specific Python minor version must
explicitly use the versioned interpreter name
(<code>python<var>X</var>.<var>Y</var></code>).

<hr>

<h3 id="s-interpreter_loc">2.4.2 Interpreter Location</h3>

Python scripts should specify the Debian Python interpreter, to ensure that the
Debian Python installation is used and all dependencies on additional Python
modules are met.

The preferred specification for the Python 3 interpreter is
<code>/usr/bin/python3</code> (or <code>/usr/bin/python3.<var>Y</var></code> if
it requires Python 3.<var>Y</var>).

The preferred specification for the Python 2 interpreter is
<code>/usr/bin/python2</code> (or <code>/usr/bin/python2.<var>Y</var></code> if
it requires Python 2.<var>Y</var>).

Scripts requiring the default Python 2 version may instead specify the
interpreter <code>/usr/bin/python</code>.

Maintainers should not override the Debian Python interpreter using
<code>/usr/bin/env <var>name</var></code>. This is not advisable as it
bypasses Debian's dependency checking and makes the package vulnerable to
incomplete local installations of Python.

<hr>

<h2 id="s-paths">2.5 Module Path</h2>

By default, Python modules are searched in the directories listed in the
<samp>PYTHONPATH</samp> environment variable and in the <samp>sys.path</samp>
Python variable. For all supported Debian releases, <samp>sys.path</samp> does
not include a <code>/usr/lib/python<var>X</var><var>Y</var>.zip</code> entry.

Directories with private Python modules must be absent from the
<samp>sys.path</samp>.

Public Python 3 modules must be installed in the system Python 3 modules
directory, <code>/usr/lib/python3/dist-packages</code>.

Public Python 2 modules must be installed in the system Python 2 modules
directory <code>/usr/lib/python2.<var>Y</var>/dist-packages</code>, where
2.<var>Y</var> is the Python 2 version.

A special directory is dedicated to public Python modules installed by the
local administrator, <code>/usr/lib/python3/dist-packages</code> for all Python
3 versions, <code>/usr/local/lib/python2.<var>Y</var>/dist-packages</code> for
Python 2.

For local installation of Python modules by the system administrator, special
directories are reserved. The directory
<code>/usr/local/lib/python3/site-packages</code> is in the Python 3 runtime
module search path. The directory
<code>/usr/local/lib/python2.<var>Y</var>/site-packages</code> is in the Python
2.<var>Y</var> runtime module search path.

Additional information on appending site-specific paths to the module search
path is available in the official documentation of the <samp>site</samp>
module.

Python modules which work with multiple supported Python 2 versions must
install to version-specific locations, for instance
<code>/usr/lib/python2.6/dist-packages/foo.py</code> and
<code>/usr/lib/python2.7/dist-packages/foo.py</code>. These should point to a
common file.

Architecture-independent public Python 3 modules must be installed to
<code>/usr/lib/python3/dist-packages</code>.

Architecture-independent public Python 2 modules should be installed to
<code>/usr/lib/python2.7/dist-packages</code>. The historical location for
this was <code>/usr/share/pyshared</code>. Since Python 2.7 is the last Python
2 version and the only supported version in Wheezy and later releases, a
version-specific location is sufficient.

<hr>

<h2 id="s-runtimes_hooks">2.6 Hooks for updates to installed runtimes</h2>

The <code>python</code> 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.

<ol type="1" start="1" >
<li>

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

</li>
</ol>
<ol type="1" start="2" >
<li>

<code>/usr/share/python3/runtime.d/*.rtremove</code>,
<code>/usr/share/python/runtime.d/*.rtremove</code>: These are called when a
runtime is removed or stops being supported. The first argument is
<samp>rtremove</samp>, and the second argument is the affected runtime (for
example <code>python<var>X</var>.<var>Y</var></code>).

</li>
</ol>
<ol type="1" start="3" >
<li>

<code>/usr/share/python3/runtime.d/*.rtupdate</code>,
<code>/usr/share/python/runtime.d/*.rtupdate</code>: These are called when the
default runtime changes. The first argument is either
<samp>pre-rtupdate</samp>, called before changing the default runtime, or
<samp>rtupdate</samp>, called when changing the default runtime, or
<samp>post-rtupdate</samp>, called immediately afterwards. The second argument
is the old default runtime (for example
<code>python<var>X</var>.<var>Y</var></code>), and the third argument is the
new default runtime (for example <code>python<var>X</var>.<var>Z</var></code>).

</li>
</ol>

<hr>

<h2 id="s-docs">2.7 Documentation</h2>

Python documentation is split out in separate binary packages
<code>python<var>X</var>.<var>Y</var>-doc</code>.

The binary package <code>python3-doc</code> will always provide the
documentation for the default Debian Python 3 version. The binary package
<code>python-doc</code> will always provide the documentation for the default
Debian Python 2 version.

TODO: Policy for documentation of third party packages.

<hr>

Debian Python Policy

<address>
version 0.10.1.1 
 
Neil Schemenauer <code><a href="mailto:nas@debian.org">mailto:nas@debian.org</a></code> 
Matthias Klose <code><a href="mailto:doko@debian.org">mailto:doko@debian.org</a></code> 
Gregor Hoffleit <code><a href="mailto:flight@debian.org">mailto:flight@debian.org</a></code> 
Josselin Mouette <code><a href="mailto:joss@debian.org">mailto:joss@debian.org</a></code> 
Joe Wreschnig <code><a href="mailto:piman@debian.org">mailto:piman@debian.org</a></code> 
Lo&iuml;c Minier <code><a href="mailto:lool@debian.org">mailto:lool@debian.org</a></code> 
Scott Kitterman <code><a href="mailto:scott@kitterman.com">mailto:scott@kitterman.com</a></code> 
Barry Warsaw <code><a href="mailto:barry@debian.org">mailto:barry@debian.org</a></code> 
Ben Finney <code><a href="mailto:ben+debian@benfinney.id.au">mailto:ben+debian@benfinney.id.au</a></code> 
 
</address>
<hr>

</body>

</html>