Greg Ewing wrote:
David Cournapeau wrote:
what is needed is a stable API for the used packages.
That's a nice ideal to aim for, but it's only achievable for old and mature packages.
Yes, many packages can't have a stable API, at least for some time. But then, should you rely on them for deployment ? I am really not convinced that you can have both stable systems and packages which keep changing whenever they want. I don't believe that library versioning will give you that, that's just a really minor part of it. When you think about it for a second, what is library versioning ? A convention to track API changes. Library versioning without API stability just does not make sense to me. What would happen if with apt-get you could install gtk 2.0, 2.2, etc... up to gtk-2.12, and gtk broke some API between minor versions ? Nothing would work, because you would quickly have one package B which work with gtk 2.8 but not above, package C which needs gtk 2.10, and package D which needs B and C. That's why you have gtk-2.n, and debian project put huge effort to be sure that with some n, many projects will work on it. If gtk is not stable, this cannot happen. I am not aware of a single big open source project which have many dependencies without strong API versioning policies (which means not breaking between minor changes). For small projects, it is no problem. For big ones, you need either to rely on strongly versioned api, or to cut dependencies (by copying a private copy: see mozilla/firefox which embed their own gecko, ardour which embeds its own gtk, sndfile which embeds its own copy of ogg, etc...)
If we all follow this convention, we will be able to install and use multiple versions of a package side-by-side just as easily as we can Python versions, with no need for setuptools or any other fancy technology -- just plain standard Python the way it currently is!
I don't see how this could work. How do you do if you have a package D which depends on both C and B, and C needs one version of one package A, and B another one ? If you cannot use a common A, this cannot work (how one python instance would use different versions of the same package ?) cheers, David