Debian Python FAQ
This is the FAQ of the email@example.com mailing list. It is of particular interest to members of the [:Teams/PythonModulesTeam: Debian Python Modules Team].
1. What are the projects and documentation available ?
If you're interested in help packaging Python itself, there's [http://alioth.debian.org/projects/pkg-python pkg-python] but if you want to help with the Python modules or packaging a new one, you should look at [:Teams/PythonModulesTeam: Debian Python Modules Team] project. Both groups discuss its activities in the same mailing list.
The Debian Python Modules Team has its own [http://python-modules.alioth.debian.org/python-modules-policy.html policy], but keep in mind that they follow [http://www.debian.org/doc/packaging-manuals/python-policy/ Debian Python Policy] and of course [http://www.debian.org/doc/debian-policy/ Debian Policy] too.
2. Supporting multiple python versions
We always have several versions of Python in Debian. Some packages provide modules only for the default version, and other provide modules for all available versions. Some sources packages do that by providing several binary packages while other do that with a single one.
We should reduce that diversity and if possible provide the modules for all python version available within Debian. The following guidelines should help you.
2.1. Build dependencies
Traditionally, Python extension modules list the development packages of all Python version they are built for in their build dependencies. For compiled modules you still have to specify each dependencies, this may be improved later. For Python-only modules, build depending on python-dev is sufficient for buildsystems made in Python (like the very used distutils), python-support will manage late-bytecompilation automagically.
2.2. Note on bytecompilation for Python-only modules
As python-support introduce late-bytecompilation, no '.py[co]' files shall be shipped in your package. You can then avoid generating such files and gain some build time. With distutils use the "--no-compile -O0" options ; if you are using the CDBS class, everything is already done for you. Beware some upstream sources contain a setup.cfg which override your build options (see #360848), then you will have to patch it. In all cases, python-support will remove those files if they are generated.
2.3. Using python-support
See /usr/share/doc/python-support/README.gz for up-to-date information.
2.4. Using python-central
You can find python-central information here: http://python-modules.alioth.debian.org/python-central_howto.txt
2.5. Should I use python-support or python-central?
Most people prefer python-support, so use that.
Some statistics, as of December 3, 2007:
bzed@hal:~/workspace/debian/python-modules$ grep pysupport */debian/rules | wc -l 117 bzed@hal:~/workspace/debian/python-modules$ grep pycentral */debian/rules | wc -l 95
3. Python eggs
3.1. What are Python eggs?
3.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. For that you need to pass the option "--single-version-externally-managed" to the "setup.py install" call.
Packages relying on CDBS can do that this way:
# Install egg-info directories DEB_PYTHON_INSTALL_ARGS_ALL += --single-version-externally-managed
3.3. How do we add Egg support to a package that doesnt support it yet?
Basicly, you should modify setup.py to use the setup function of "setuptools" instead of "distutils". Of course, you must then Build-Depends on "python-setuptools (>= 0.6a9)" which is the first version supporting the egg-info directories.
Check the following links for documentation about setuptools and creation of Eggs:
Example of minimal patch:
--- elementtree-1.2.6.old/setup.py 2006-04-18 12:25:33.000000000 +0000 +++ elementtree-1.2.6/setup.py 2006-04-18 12:26:30.000000000 +0000 @@ -7,6 +7,7 @@ # from distutils.core import setup +from setuptools import setup try: # add download_url syntax to distutils
Adding "egg support" is only required in some specific cases: when another software uses the python module via an egg and when this egg support is not yet integrated upstream.