[Robert Collins, 2011-01-06] > 2011/1/6 Piotr Ożarowski <piotr@debian.org>: > This issue exists with C libraries too, but its not forbidden. Why > should C libraries be expected to permit this, but not Python > libraries? C libraries are linked at build time, Python libraries at runtime and C libraries do not suffer from sys.modules problem, that's a huge difference [...] > > 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() if you mean pkg_resources.require() (i.e. the one I mentioned above), then please check when it's possible to use it and then think what will happen if application A will *not* use pkg_resources.require -- 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
Attachment:
signature.asc
Description: Digital signature