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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
