Differences between revisions 1 and 28 (spanning 27 versions)
Revision 1 as of 2006-06-14 21:42:15
Size: 1037
Comment:
Revision 28 as of 2010-07-23 11:05:32
Size: 3746
Editor: UmangVarma
Comment: added comment on distutils' /usr/local/ installation target (as opposed to the upstream sys.prefix)
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Python in Debian = <<TableOfContents(3)>>
Line 3: Line 3:
Python compiler in Debian project is maintained by a developers team known as [http://alioth.debian.org/projects/pkg-python pkg-python]. There are many Python modules and extensions maintained by individual developers and by a coordinated group called [http://python-modules.alioth.debian.org Debian Python Modules Team]. The Debian project counts with many other applications written in Python. == Python in Debian ==
Within the Debian project Python packages are maintained by individual developers and three main teams :
Line 5: Line 6:
== Status ==  * [[http://alioth.debian.org/projects/pkg-python|pkg-python]] maintains the Python compiler/interpreter package.
Line 7: Line 8:
Debian latest release Sarge, contains multiple Python versions: 2.1, 2.2, 2.3, 2.4. Unfortunately not all the modules, extensions and applications supports every version and support four different Python versions simultaneously with a good quality isn't so easy.  * [[Teams/PythonModulesTeam|Debian Python Modules Team]] maintains some Python modules and extensions.
Line 9: Line 10:
We're working right now in a better infrastructure for transitions between versions and hopefully we will just include Python 2.4 in our next release to turn the support easier. Actually Debian Unstable (also known as sid) contains Python 2.3 (as default) and Python 2.4 only.  * [[Teams/PythonAppsPackagingTeam|Python Applications Packaging Team]] maintains some Python applications.
Line 11: Line 12:
== Python Policy == There are also :
 * [[http://lists.debian.org/debian-python/recent|debian-python mailing list]] with all development discussions
 * [[irc://irc.oftc.net/debian-python|#debian-python]] [[IRC]] channel
 * [[DebianPythonFAQ|FAQ]]
Line 13: Line 17:
See DebianPython/NewPolicy == Supported Python Versions ==
Debian's latest release Lenny contains multiple Python versions: 2.5 (the default) and 2.4.

 * Python 3.1 is in [[DebianPts:python3.1|testing]]
 * Python 2.7 is in [[DebianPts:python2.7|experimental]]
 * Python 2.6 is in [[DebianPts:python2.6|testing]]
 * Python 2.5 is in [[DebianPts:python2.5|stable and testing]]
 * Python 2.4 is in [[DebianPts:python2.4|Lenny]]


== Debian Python Policy for Python developers ==
The Debian Python Policy describes conventions for packaging and distributing Python code in Debian.

The official text is located at http://www.debian.org/doc/packaging-manuals/python-policy/.

Feel free to ask any questions on debian-python@list.debian.org mailing list.

if you want to maintain a Python package, you have to know how the [[DebianDevelopment|Debian Development]] works.

== Deviations from upstream ==
Debian distributions modify upstream Python in a few ways that are important to understand. Of course, where at all possible, we try to minimize deviations from upstream, but here is an enumeration of the changes you might encounter on a Debian system (and derivatives, such as [[http://www.ubuntu.com|Ubuntu]]).

 * `dist-packages` instead of `site-packages`. Third party Python software installed from Debian packages goes into `dist-packages`, not `site-packages`. This is to reduce conflict between the system Python, and any [[http://www.python.org/download/|from-source Python build]] you might install manually.
 * The `python-setuptools` package installs the [[http://packages.python.org/distribute/|Distribute]] fork instead of the standard [[http://peak.telecommunity.com/|setuptools]].
 * The `python-virtualenv` also uses `distribute` by default, but can enable classic `setuptools` with an optional switch.
 * `distutils` setup scripts install files in `/usr/local/` not `sys.prefix` (which is normally `/usr/`). This is because `/usr/` is reserved for files installed from Debian packages. Note that `/usr/local/lib/pythonX.Y/dist-packages` is in `sys.path` so that modules not installed from Debian packages can still be accessed by the system Python. Tools like debhelper pass the `--install-layout=deb` option to the setup script while building a Debian package so that its installs files into `/usr/` not `/usr/local/`.
 *

== Current regretful practices ==
 * Tests from distributed packages are usually stripped, so it is not possible for user to run them to ensure that package works as expected. This assumes that package maintainers run tests for all possible system configurations. This also makes troubleshooting harder.
 * -dbg packages are not commonly built/packaged for modules with extensions. GDB gets constantly improving allowing to easier debugging of Python modules, and extensions built using python*-dbg libraries are necessary to take advantage.

== See also ==
 * [[Python]]
 * [[IRC/debian-python/FAQ]]
 * [[DebianPython/Namespaces]]
 * [[DebianPython/Policy]]

Python in Debian

Within the Debian project Python packages are maintained by individual developers and three main teams :

There are also :

Supported Python Versions

Debian's latest release Lenny contains multiple Python versions: 2.5 (the default) and 2.4.

Debian Python Policy for Python developers

The Debian Python Policy describes conventions for packaging and distributing Python code in Debian.

The official text is located at http://www.debian.org/doc/packaging-manuals/python-policy/.

Feel free to ask any questions on debian-python@list.debian.org mailing list.

if you want to maintain a Python package, you have to know how the Debian Development works.

Deviations from upstream

Debian distributions modify upstream Python in a few ways that are important to understand. Of course, where at all possible, we try to minimize deviations from upstream, but here is an enumeration of the changes you might encounter on a Debian system (and derivatives, such as Ubuntu).

  • dist-packages instead of site-packages. Third party Python software installed from Debian packages goes into dist-packages, not site-packages. This is to reduce conflict between the system Python, and any from-source Python build you might install manually.

  • The python-setuptools package installs the Distribute fork instead of the standard setuptools.

  • The python-virtualenv also uses distribute by default, but can enable classic setuptools with an optional switch.

  • distutils setup scripts install files in /usr/local/ not sys.prefix (which is normally /usr/). This is because /usr/ is reserved for files installed from Debian packages. Note that /usr/local/lib/pythonX.Y/dist-packages is in sys.path so that modules not installed from Debian packages can still be accessed by the system Python. Tools like debhelper pass the --install-layout=deb option to the setup script while building a Debian package so that its installs files into /usr/ not /usr/local/.

Current regretful practices

  • Tests from distributed packages are usually stripped, so it is not possible for user to run them to ensure that package works as expected. This assumes that package maintainers run tests for all possible system configurations. This also makes troubleshooting harder.
  • -dbg packages are not commonly built/packaged for modules with extensions. GDB gets constantly improving allowing to easier debugging of Python modules, and extensions built using python*-dbg libraries are necessary to take advantage.

See also