dead links removed
|Deletions are marked like this.||Additions are marked like this.|
|Line 20:||Line 20:|
|[[ReleaseGoals/Python2.6|Python 2.6 as default]] is a goal for squeeze
|Line 34:||Line 32:|
|Feel free to ask any questions on firstname.lastname@example.org mailing list and contribute to [[DebianPython/Tutorial]].||Feel free to ask any questions on email@example.com mailing list.|
Python in Debian
Within the Debian project Python packages are maintained by individual developers and three main teams :
pkg-python maintains the Python compiler/interpreter package.
Debian Python Modules Team maintains Python modules and extensions.
Python Applications Packaging Team maintains some Python applications.
There are also :
debian-python mailing list with all development discussions
Supported Python Versions
Debian's latest release Lenny contains multiple Python versions: 2.5 (the default) and 2.4.
Python 3.1 is in testing
Python 2.7 is in experimental
Python 2.6 is in testing
Python 2.5 is in stable and testing
Python 2.4 is in 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 firstname.lastname@example.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-virtualenv also uses distribute by default, but can enable classic setuptools with an optional switch.
- 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.