David Cournapeau wrote:
Greg Ewing wrote:
If they really do need different versions, this is insoluble.
But that's by far the most significant problem of packages with a lot of dependencies !
But if your application really does depend on two libraries that have conflicting requirements like this, the application itself is screwed to begin with. There's *no* way of making it work on *any* system, whether that system has library versioning or not. Consequently, the developer will be unable to make it work on his own machine, and will therefore never attempt to deploy it!
It is ok to have a few major, side by side versions for fundamental packages (on my ubuntu system, I do have system installed qt 3 and qt 4, for example). This would be good to have in python, I agree.
That's what I'm talking about! As long as the API remains backward compatible, there is no need to have anything but the latest version installed -- and in fact, in the kind of system I have in mind, the earlier versions would *never be used* even if they were installed. That's because the program would say something like "Please give me gtk-2.3", and the system would know that anything called gtk-2.x with x >= 3 is compatible with that, and would pick the one with the greatest x out of those available. However, if a gtk-3.0 ever comes out, it implies that the API is *not* backward compatible. So then it makes sense to have both a gtk-2.x and a gtk-3.y installed, and the versioning system will keep them from getting confused. This relies on a couple of things: (a) library developers sticking rigidly to the version numbering semantics; (b) applications always requesting the version they actually require.
IOW, enabling version requirement without strong API compatibility is the path to dependency hell.
I fully agree. However, this is a social issue, not a technical one. Everyone using the versioning system would need to understand the rules and be willing to follow them. -- Greg