site-packages versus site-python

[enrio]

I recently installed python 2.4, and many installed software packages
stopped working. Some things got working after I copied some files and
directories from /usr/lib/python2.3/site-packages to
/usr/lib/python2.4/site-packages, but I also had to install a newer
PyXml package, as some of the files that came with python2.4 required a
newer version of pyxml than I had in python2.3/site-packages.

I wonder if there is any particular reason I have no
/usr/lib/site-python directory, and everything is installed in
version-specific site-packages.

I have Fedora Core 3. Is it the Fedora packagers who prefer installing
everything in the version-specific directory? Is there no way to have
older packages continue working in the presence of python2.4? (I still
want the newest to be the default!)

I have tried (cd /usr/bin; grep '#!.*python' * 2>/dev/null), and very
few of the programs have a specific version in the interpreter line. Is
there any good reason this is so?

Thinking about it, a particular python program may require a particular
module, but not any particular version of python or the module. The
module perhaps requires at least python2.3, but could run just as well
with python2.4 or later. It does not make sense to have the program
demand a particular version of python in its interpreter string (e.g.,
"#!/usr/bin/python2.3"), but what about the module. Would it be better
to put the module in site-python and include code to check the
interpreter version?

Perhaps there is no perfect solution that covers all permutations, but
on the other hand, what is currently the "correct philosophy" of
version handling?

[Steve Holden]

en***@online.no wrote:

I recently installed python 2.4, and many installed software packages
stopped working. Some things got working after I copied some files and
directories from /usr/lib/python2.3/site-packages to
/usr/lib/python2.4/site-packages, but I also had to install a newer
PyXml package, as some of the files that came with python2.4 required a
newer version of pyxml than I had in python2.3/site-packages.

I wonder if there is any particular reason I have no
/usr/lib/site-python directory, and everything is installed in
version-specific site-packages.
Well, broadly, the reason is that it allows version-specific code to be
included in libraries.

Of course, Python is so good at maintaining backward compatibility that
it's unlikely a pure Python module will fail to run on the next version
of Python. But you have to do this for extension modules, where the code
is compiled against a specific version of the Python interpreter API,
which doesn't stay the same from one version to the next.
I have Fedora Core 3. Is it the Fedora packagers who prefer installing
everything in the version-specific directory? Is there no way to have
older packages continue working in the presence of python2.4? (I still
want the newest to be the default!)

I have tried (cd /usr/bin; grep '#!.*python' * 2>/dev/null), and very
few of the programs have a specific version in the interpreter line. Is
there any good reason this is so?

Thinking about it, a particular python program may require a particular
module, but not any particular version of python or the module. The
module perhaps requires at least python2.3, but could run just as well
with python2.4 or later. It does not make sense to have the program
demand a particular version of python in its interpreter string (e.g.,
"#!/usr/bin/python2.3"), but what about the module. Would it be better
to put the module in site-python and include code to check the
interpreter version?

Perhaps there is no perfect solution that covers all permutations, but
on the other hand, what is currently the "correct philosophy" of
version handling?

The current "correct" philosophy is to have version-specific libraries.
Of course, there is nothing to stop you building your own
*no*-version-specific library directory and configuring it on to the
PYTHONPATH for each version you run.

regards
Steve
--
Meet the Python developers and your c.l.py favorites March 23-25
Come to PyCon DC 2005 http://www.pycon.org/
Steve Holden http://www.holdenweb.com/

[msoulier]

> Well, broadly, the reason is that it allows version-specific code to
be

included in libraries.

I've actually found this to be a bit of a pain. I build packages
against say, python2.2, and if you upgrade python to 2.3 the package
breaks. The code works fine so saying it requires python >= 2.2 should
be valid, but the version-specific path prevents that.

Mike

[Steve Holden]

msoulier wrote:

Well, broadly, the reason is that it allows version-specific code to

be

included in libraries.

I've actually found this to be a bit of a pain. I build packages
against say, python2.2, and if you upgrade python to 2.3 the package
breaks. The code works fine so saying it requires python >= 2.2 should
be valid, but the version-specific path prevents that.

Mike

Well, if you can invent a reliable mechanism for managing
version-independent extensions I'm sure the developers will be happy to
hear about it :-)

regards
Steve
--
Meet the Python developers and your c.l.py favorites March 23-25
Come to PyCon DC 2005 http://www.pycon.org/
Steve Holden http://www.holdenweb.com/