Distributing compiled (swig) python modules

[mathieu]

Hi there,

I have prepared binaries of a python module that I wrote. Basically
the lib is written in C++ and wrapped in python using SWIG. Of course
it links to the python dynamic libraries. I found out that this is
version dependant. For instance if I prepare the binaries on my
machine with a python 2.4 installation this module will not load
properly on a python 2.5 / 2.6 installation.

Is there some documentation (that I missed in my previous google
search) that describe how to prepare python module that can be
redistributed with some kind of backward compatibility (= so that when
prepared on python 2.4, it works on 2.5/2.6 at least) ?

Thanks

[Diez B. Roggisch]

mathieu wrote:

Hi there,

I have prepared binaries of a python module that I wrote. Basically
the lib is written in C++ and wrapped in python using SWIG. Of course
it links to the python dynamic libraries. I found out that this is
version dependant. For instance if I prepare the binaries on my
machine with a python 2.4 installation this module will not load
properly on a python 2.5 / 2.6 installation.

Is there some documentation (that I missed in my previous google
search) that describe how to prepare python module that can be
redistributed with some kind of backward compatibility (= so that when
prepared on python 2.4, it works on 2.5/2.6 at least) ?

There is no such way, and can't be because of C-API-changes in python.dlls.
You will have to offer your library separately for each python version you
support.

I don't know too much about SWIG, but if you can make your whole
build-process based on distutils or setuptools, you should be able to
produce eggs to install that your users then can install very easy.

Diez

[Scott David Daniels]

mathieu wrote:

>...Is there some documentation (that I missed in my previous google
search) that describe how to prepare python module that can be
redistributed with some kind of backward compatibility (= so that when
prepared on python 2.4, it works on 2.5/2.6 at least) ?

Nope, you didn't miss it. Each major version change (2.3.X -2.4.X,
2.4.X -2.5.X, ...) changes the Python VM and internals. There is no
way below Python source (.pyc, .pyo, or .pyd) to stay compatible. That
is why Python projects offer code in Python version-specific packages.

--Scott David Daniels
Sc***********@Acm.Org