[Distutils] Simple idea to resolve versioning problems

[David Cournapeau]

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