Re: coming back to packaging multiple versions of libraries
[Robert Collins, 2011-01-03]
> 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
what's the point of installing two different versions of the same module
if only one will be used anyway? If the answer to that question is:
"in the application where I need different version, I will adjust
sys.path" - why not simply provide different version of the library as
private module? Security team will hate you anyway.
> I'm very interested in other approaches to make this work;
teach upstream about the importance of stable API (yeah, I know Python
programmers do not care about it much, it could be worse¹, though)
You could also provide wadllib/__init__.py file which will modify
__path__ to point to the newest installed versions (and f.e. check for
WADLIBVERSION env. variable if someone doesn't want the newest version)
but it's an ugly hack and could cause more harm than good, IMHO.
[¹] imagine packaging something written in Ruby
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Reply to: