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 ! And by enabling multiple versions, side by side, you will make this problem more pervasive. I don't know if you have experience with packaging on linux systems, but if it was allowed multiple versions of the same library (say gtk 2.4, gtk 2.6, etc...) with incompatible changes of API in between, it would be a nightmare. What will happen if multiple versions of the same package are allowed in python ? Everyone will start to say :I need version == N, and quickly, it will be unmanageable, because the above diamond diagram A <- (B <- D1, C <- D2) will happen all the time. You really need to be able to say I need version >= N, which means maintaining API. 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. So my point is that package versioning only work if you can depends on one version and all revision after, which means side by side installation of several minor revisions does not help. Having 2,3 major different versions of the same package is OK, if the package changes say every two years (like python). But it won't work if it changes every month (imagine what would happen if python 2.3.1 was not compatible with 2.3.2 ?) IOW, enabling version requirement without strong API compatibility is the path to dependency hell. If you enable side by side installation of many versions of the same package, you will make the problem worse, not better. If you need to use a package without strong API compatibility commitment, then the only real solution is to make your own copy. cheers, David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
