Creating an RPM which works with multiple Python versions?

[Edwin Young]

Hi,

I'm developing an application which is primarily in Python but has
some C-coded extension modules. These modules aren't really useful to
anyone other than the main application. The app works fine with Python
2.2 or 2.3, so ideally I'd like to create one install package which
works with both.

I have installation largely working using distutils to create a source
tarfile and an RPM package. However I've noticed that the RPM installs
the extension libraries to /usr/lib/python2.2/site-packages, even if
python2.3 is the only version installed on the target machine - in the
latter case, my app won't work. If I move the files to the python2.3
lib dir, it all seems to work, except that I get a RuntimeWarning at
startup, indicating that the C libs were compiled against a different
Python API version.

What's recommended here? I can see 3 options:

1) Somehow convince RPM to install the extensions to the directory for
the version of Python that's installed. Any clues how?

2) Produce separate 2.2 and 2.3 packages. This is kind of a pain for
users, so I'd rather not if possible.

3) Install the modules somewhere unrelated to the python tree (eg
/usr/lib/appname-appver/ and change the python library path in the
app to find them.

Any suggestions?

Also, how can I tell if the RuntimeWarning is important? (and eliminate
it, if not?) I make fairly minimal use of the API and everything
*looks* like it works, but I don't want to risk memory corruption.

Thanks,
--
Edwin

[Roger Binns]

Edwin Young wrote:

2) Produce separate 2.2 and 2.3 packages. This is kind of a pain for
users, so I'd rather not if possible.
That is standard practise for distributing binary Python modules. Look
at wxPython, win32all etc
Any suggestions?

You could distribute your app as a whole without relying on an installed
Python or any other libraries.

If you want an example, have a look at dotamatic.sourceforge.net which
ships Windows, Linux and Mac "binaries". In the source, makedist.py
is the script that produces the right thing on each platform and
the help lists the components used.

Roger

[Martin v. Löwis]

Edwin Young wrote:

What's recommended here?

There is a fourth one: Install to /usr/lib/site-python. This
is a location that is shared across different Python releases.

Be careful not to put bytecode files into this location, since
bytecode files may become invalid across Python releases.

Regards,
Martin

[Edwin Young]

"Martin v. Löwis" <ma****@v.loewis.de> writes:

[You can] Install to /usr/lib/site-python. This
is a location that is shared across different Python releases.

Be careful not to put bytecode files into this location, since
bytecode files may become invalid across Python releases.

It seems like "setup.py bdist_rpm" by default creates an archive
containing .pyc files, so the RPMs it creates are effectively bound to
a specific Python version, even if no C-coded extensions are involved.

However I believe that if the .pyc is for the wrong interpreter
version, Python will ignore it and use the .py instead, so the only
effect will be longer startup time.Can anyone confirm or deny?

--
Edwin