Re: coming back to packaging multiple versions of libraries
2011/1/6 Piotr Ożarowski <piotr@debian.org>:
> IMHO installing two versions of the same (public) Python module should
> be simply forbidden in policy. For one simple reason: if module foo uses
> bar in version 1 and spam uses bar in version 2, imagine what will
> happen with egg which uses both foo and spam.
This issue exists with C libraries too, but its not forbidden. Why
should C libraries be expected to permit this, but not Python
libraries?
> Right now I see only these options:
> 1) create separate binary packages for both versions of bar conflicting
> with each other
> 2) install only one version of bar as public module and the second one as
> private module
Neither of these meet the use cases I've described comprehensively before.
> 3) convince library author(s) to *not* break API so often (6 months? 1
> year?)
Once is enough; the ecosystem is huge and unless we handle transitions
gracefully we'll get into nightmare situations routinely - which we do
on complex stacks (like zope) on a regular basis.
> 4) convince library author(s) to rename it (bar, bar2, bar3, etc.) once
> he/she decides to break API
I'm not sure that this is necessary or worth it. Certainly you'd need
a massive change in the culture of Python upstream (python *itself* to
have this act as a systematic fix).
> 5) convince Python interpreter developers to provide something similar to
> sonames (bar.py, bar.2/__init__.py, bar.2.3/__init__.py, bar.3.py)
> and add support for syntax I mentioned last time or use something
> like 3rd party pkg_resources' require() or... allow
> foo/lib-packages/bar → ../../bar-1 symlinks (where dist-packages/bar
> is in version 2 and dist-packages/bar-1 in v1, note that bar-1 is not
> a valid module name)... with lots of problems Clint already mentioned
Its already developed : pkg_resources.Require()
I'm working on the mechanics to get default programs working; once
thats done things using the soname equivalent should be trivial.
-Rob
Reply to: