Differences between revisions 15 and 16
Revision 15 as of 2006-06-04 16:21:13
Size: 7945
Editor: ?Duck
Comment: clarifications about python-central
Revision 16 as of 2007-03-15 21:42:22
Size: 4345
Editor: ?JossMouette
Comment:
Deletions are marked like this. Additions are marked like this.
Line 24: Line 24:
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. 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.
Line 28: Line 28:
A non-binary module (i.e. package with architecture: all) can use python-support to make the module available to all available Python versions. For this you need to install the module in a sub-directory of /usr/share/python-support and then you need to register that directory with update-python-modules in the postint (and unregister accordingly in prerm). Of course you need to add "python-support" as a dependency. Please note that the default Depends field generated by dh_python is wrong since the package now supports multiple versions. Until this is fixed you need to manually define the dependency (like "python (>=2.3), python (<< 2.5)", if you say that you support python 2.3 and python2.4).

Example of postinst:
{{{
#!/bin/sh

set -e

#DEBHELPER#

if [ "$1" = "configure" ] && which update-python-modules >/dev/null 2>&1; then
        update-python-modules -i /usr/share/python-support/kid
fi
}}}

Example of prerm:
{{{
#!/bin/sh

set -e

#DEBHELPER#

if which update-python-modules >/dev/null 2>&1; then
        update-python-modules -c -i /usr/share/python-support/kid
fi
}}}

If you are using CDBS, a sample debian/rules file looks like this:

{{{
#!/usr/bin/make -f
# -*- mode: makefile; coding: utf-8 -*-

# python-distutils before debhelper to avoid it calling dh_python by itself
include /usr/share/cdbs/1/class/python-distutils.mk
include /usr/share/cdbs/1/rules/debhelper.mk

DEB_PYTHON_INSTALL_ARGS_ALL += --install-lib usr/share/python-support/$your-package

# If you have an additional documentation package, you have to remove *.py files
# from this package, otherwise the following target isn't needed at all
common-binary-post-install-indep::
        rm -rf debian/$your-package-doc/usr/share/python-support
}}}

A sample debian/control.in file :

{{{
Source: $your-source-package
Section: python
Priority: optional
Maintainer: Maintainer name and email
Uploaders: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org>
Standards-Version: 3.6.2
Build-Depends: @cdbs@, python-dev

Package: $your-package
Architecture: all
Depends: python (>= 2.3), python-support (>= 0.2)
Description: your description
}}}

If you are using this sample, you have to generate the debian/control file (otherwise you should replace @cdbs@ by cdbs and debhelper depends) using the following command line :
{{{
$ DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes fakeroot debian/rules clean
}}}

Concerning CDBS, there is an interesting documentation :
[https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml]

(TODO: extend sample for egg support)

=== Converting to python-support ===
If your package python-foo previously provided packages for several Python versions (python2.3-foo, python2.4-foo), you should do the following:
 * check if any other packages depend on something else than python-foo. If any package does
   * add python2.3-foo, python2.4-foo to the "Provides" field of your package
   * file bugs for these packages, mentioning the transition
   * drop them after the other packages have been fixed
 * add python2.3-foo and python2.4-foo to the "Conflicts" and "Replaces" field. This will force their uninstallation if python-foo is upgraded to the new version.
See /usr/share/doc/python-support/README.Debian for up-to-date information.
Line 111: Line 32:
python-central is another tool made by doko to achieve the same goal as python-support. This one is not in the Debian archive and should then not be used. python-central's ideas may, or may not, be merged into python-support in the future, when it has been discussed on the mailing-list (which has not yet really happened). So, please use python-support instead.
Line 115: Line 34:

Doko's personal plans for Python in Ubuntu (not yet discussed in Debian):
https://wiki.ubuntu.com/PythonRoadmap

Debian Python FAQ

This is the FAQ of the debian-python@l.d.o mailing list. It is of particular interest to members of the [http://python-modules.alioth.debian.org/ 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 [http://python-modules.alioth.debian.org Debian Python Modules Team] project. Both groups discuss its activities in the same mailing list.

1.1. python-modules

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.Debian for up-to-date information.

2.4. Converting to python-central

You can find python-central information here: http://python-modules.alioth.debian.org/python-central_howto.txt

3. Python eggs

3.1. What are Python eggs?

http://peak.telecommunity.com/DevCenter/PythonEggs

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.