On Jan 05, 2011, at 11:40 PM, Piotr Ożarowski wrote: >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. Hilarity ensues? No, that's not quite right. Insanity. But anyway, such choices must be done at the application level, not at the library level. You just cannot safely integrate two libraries that require different versions of dependent 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 >3) convince library author(s) to *not* break API so often (6 months? 1 > year?) >4) convince library author(s) to rename it (bar, bar2, bar3, etc.) once > he/she decides to break API >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 > >my current vote is: 3, 4, 2 (if only one application uses it), 1, none >of the above, 5 These are not necessarily mutually exclusive. ;) #3 and #4 are both worth pursuing in any case, but kind of outside the domain of either upstream (except were the stdlib is concerned) or debian-python. Still, as a Python programmer, if you find gratuitous API breaks in packages you care about, it's worth a bug report. (I'm still not quite sure why Robert doesn't just get the wadllib developers to fix their API breakage?) I really hate having the version numbers in the module names, and actually in package names too, but the latter tend to disappear after transitional periods. Names like urllib2 live forever unfortunately. I don't have any great ideas about how to improve that though. I agree with Piotr, I think trying to do this in a hidden way is fraught with problems and lots of unanswered questions. I will mention that for years Mailman shipped with its own version of the email package because it needed an exact API that might have been different than the default one, depending on the version of Python you were using. So a specific application that cares deeply about its library versions I think has no better choice than to do something like that, which is essentially your #2. There can be more principled ways of doing that, e.g. with buildout or virtualenv, but it boils down to the same thing. There's just no good distro-way of doing that though. -Barry [*] In a previous life I did a lot of development on Windows and it was possible to combine two different C run times in a Python embedded app. You were lucky if all your app did was crash when you passed FILE*'s from one to the other. Another anecdote: JWZ famously hated shared libraries for a similar reason and always recommended static linking. Same problem, different domain.
Attachment:
signature.asc
Description: PGP signature