2011/1/6 Piotr Ożarowski <pi...@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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=j9z+ddf3vdz5lcu3f9__c9zzypff+3qrta...@mail.gmail.com