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.
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 -- 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
signature.asc
Description: Digital signature
