coming back to packaging multiple versions of libraries
So in the thread 'Python packaging, dependencies, upstream facilities'
we had a brief talk that faded out; rather than resurrecting the
entire thread, I'd like to pick one point that seems like a necessary
condition to me: installing the eggs in versioned paths rather than
simple module paths.
Take something like wadllib - a library which has had the odd
effective api break without a namespace change. We currently install
its contents as:
/usr/share/pyshared
/usr/share/pyshared/wadllib
...
/usr/share/pyshared/wadllib-1.1.4.egg-info
/usr/share/pyshared/wadllib-1.1.4.egg-info/PKG-INFO
...
So the question is:
whats the simplest way to install this somewhere else - e.g.
/usr/share/pyshared/wadllib-1.1.4
and have
import wadllib
still work without user intervention.
Two options seem to present themselves to me at the moment:
- the pyshared symlink logic could select the highest version and
link that into /usr/lib/.../wadllib as well as into
/usr/lib/.../wadllib-1.1.4
- possibly using a single wadllib->wadllib-1.1.4 symlink, or
possibly using the 'normal' structure of directories + per-file links.
- we could drop the versioned path into site.py in the same way
python-numeric etc do
I'm very interested in other approaches to make this work; the reason
for doing it were covered in the other thread, but making this one
case work would allow having two packages with slightly different
versions of something to coexist - which is immensely useful for
application (vs library) developers when developing for multiple
versions of dependencies.
It seems to me that the first option is the most efficient performance
wise for now; we should get better upstream support to, of course.
-Rob
Reply to: