Deploying Python modules in an Ubuntu system with distutils and deb

Question

I am working on packaging some libraries up in a deb with distutils.

Presumably, I need to have setup.py configured correctly, as well as the appropriate /debian files for the deb.

Right now, the repository looks something like this:

library_name/
 __init__.py
 liba.py
 libb.py
 ...

It's being added as a dependency to other programs so they can execute from library_name import liba.

Googling reveals something between 3 and 5 different methods of deploying on Ubuntu, not including the easy_install approach; the documentation appears to be largely in pieces and out of date.

I particularly am looking to ensure that regardless of the Python version, the library is placed in the correct system directory. Also, of course, that it can be uninstalled or upgraded seamlessly.

The endgame is to have a deb on a local server that is added as a package dependency for our other programs.

What is the canonical "easy and straightforward" way to get this done?

Answer 1

You can use pkgme to create the debian files quite fast. As far as I know, unlike other similar tools like dh-make, pkgme design is based on plugins which means that when python is detected the information from your setup.py file is correctly extracted.

For more information, you can have a look at this recent talk at the Ubuntu Developer Week event.

Answer 2

I've battled with Python packaging for Ubuntu/Debian before as well, and I agree, the docs are a mess/non-existent/misleading: they really need a quickstart guide for the simplest possible situation.

Well, here it is!

Install your tools. This might be overkill, though:

sudo apt-get install build-essential python-all dh-make devscripts fakeroot

Start with your code checked out into a directory named $packagename-$version, like library_name-0.6.0/, and cd to that directory. Run something like dh_make -i -c gpl3 -e [email protected] (see dh_make --help for other options). If everything goes well, you'll get no errors, and it'll create a load of files in ./debian. You can ignore or delete ./debian/*.{ex,EX}; those are just examples.

You should probably examine all these files at some point, but at the very least, you need to edit ./debian/control and ./debian/rules. You should fill out all templately fields in control, namely Description and Homepage. Change the Package line to python-$libname Change your Depends line in control to this:

Depends: ${misc:Depends}, ${python:Depends}

It ensures that our binary package python-$libname depends on the versions of Python it needs. (${python:Depends} is a "substvar"; they're created when we build; you can inspect their values after your first build in./debian/$packagename.substvars`.)

Change the line in rules from dh $@ to dh $@ --with python2, preserving the tab at the front (it's a Makefile). This causes debhelper to use its python2 addon; the default is still to use pysupport (which is deprecated, remember?).

Then, run the following command in the source root:

debuild -us -uc

This builds the package, without signing it (something you should learn how to do later!). You should see some familiar setuptools lines (twice: once for 2.6, once for 2.7), piles of dh_ addons, and other building cruft. At the end is the output of lintian, which can detect some common packaging problems; you should fix these. A lot of the stuff that lintian and friends complain about are just adherence to the packaging rules, and if your lib's just internal, feel free to play it loose.

By the way, This page talks about the deprecation of python-support and python-central