[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Packaging applications with extensions modules



We[0] have a Python application, which includes Python modules that are not supposed to be used by any other software. Some of them are extension modules. What is the best way to package such applications? I can think of the following approaches:

A) Install the modules to dist-packages. This is often what upstream supports, making it the cheapest solution. It's also well supported by Python helpers. Unlike some of the other methods, it allows shipping extension modules for multiple Python versions. The downside is that it causes namespace pollution, sometimes to the point it's completely unacceptable (like in the case of the package I'm having currently in mind).

B) Like in A, install the module to dist-packages, but put them in a namespace clearly indicating that it is private, i.e. starting with an underscore. This has most of the advantages of A, with pollution reduced significantly.

C) Built the modules only for the default Python version and install them to a private directory (/usr/lib/PKGNAME/ or similar). This is what Python Policy tells us to do. I see the following problem with this approach: - You can ship extensions only for one Python version. (Arguably that's not a big deal.) - Unless you write the code yourself, there is no protection against loading extensions modules for a wrong Python version. - dh_python2 (which, for some reason, everyone wants to use) doesn't generate §3.1.1-compliant dependency for such setup.

D) Install the modules into a private, Python-version-specific directories (say /usr/lib/PKGNAME/python2.X/). This is a clever way of working around some problems with C. Unfortunately, unless upstream supports such setup (very unlikely), it requires patching every script. Worse, no Python helpers support this method, so you'd have to write maintainer scripts and generate dependencies yourself.


I'm currently leaning towards B, although I'm not aware of any packages using this method, so I thought I'd ask here first.


[0] We, the King of... er, wrong mail; let me try again:
We, that is me and my sponsoree: http://bugs.debian.org/696782

--
Jakub Wilk


Reply to: