> 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.
Do you care to elaborate on how apt has shown that? I use it every day (or at least often), but I have to admit I never delved to deeply into them - to me it appears that apt is a retrieval-solution, not so much a dependency management system. The dependencies are declared in the debs themselves, used by dpkg-* - aren't they? Sure, apt does solve them, but how so decoupled from the underlying .deps? Regarding smart: what I read here """ Smart is not meant as an universal wrapper around different package formats. It does support RPM, DEB and Slackware packages on a single system, but won't permit relationships among different package managers. While cross-packaging system dependencies could be enabled easily, the packaging policies simply do not exist today. This is not at all different from what you can already do. In fact, Debian has been shipping the RPM package manager for a few years now. "Possible" does not equal "good idea", and everybody should stick to their native package format. """ in the FAQ doesn't make me think that it's just a matter of unwillingness from the setuptools-people but instead an intrinsic property of dependency-handling that makes cross-package-management-management (or meta-management) hard. Apart from the technical intricacies of .deb/.rpm and their respective tools, on thing sure makes this an argument: THEY evolve as they like, and it sure puts a lot of additional burden to the setuptools-guys to keep track with that. > 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. Certainly a nice solution to a real problem that might be handy for me at some time. Yet I fail to see how that relates to the above question: if the OS package repository fails to meet a certain version requirement, how do you deal with that - installation local to the product you're actually interested in installing, or in a more public way that possibly interferes with other software? Diez -- http://mail.python.org/mailman/listinfo/python-list
