On 26 Sep, 11:16, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > Generally speaking, I think the real problem here is the clash > between "cultures" of dependency-handling. But it's certainly beyond > setuptools scope to cope with every imaginable package management system > out there, and provide means to trigger an installation of say e.g. debian > packages that are needed.
If you look at PEP 345... http://www.python.org/dev/peps/pep-0345/ ...you'll see that the dependency information described is quite close to how such information is represented in Debian packages and with other dependency management systems. This isn't an accident because the authors were surely already familiar with such representations, which have been around for quite some time. Admittedly, it isn't easy to make a system which observes the rules of all the different existing systems; for example, can .deb metadata and .rpm metadata be interpreted in the same way and be taken to mean the same thing? However, the argument that a dependency manager cannot deal with different system packages is a weak one: apt and Smart have shown that dependency management can be decoupled from package management. Of course, I've already pointed out that despite being written in Python, there's apparently no interest in the setuptools community to look at what Smart manages to do, mostly due to spurious licensing "concerns", and there's always the "argument zero" from people who choose to ignore existing dependency management solutions: that Windows doesn't provide such solutions - which is apparently not entirely true, either. [...] > For example - what if there is no debian package that provides module XY in > the required version? Do you rather install it into the global > site-packages, or do you rather keep it private to the program requiring > it? I'd say the latter is better in mostly all circumstances, as it will > not disrupt the workings of other programs/modules. For what it's worth, it is possible to use Debian dependency/package management as a non-root user with a local site-packages directory, but it isn't particularly elegant. See this proof of concept for details: http://www.boddie.org.uk/paul/userinstall.html It's a fairly heavy solution which installs a lot of the administrative toolchain just for local package installations, but you do get dependency integration with the packages providing the libraries that may be required by various Python extension modules. Paul -- http://mail.python.org/mailman/listinfo/python-list
