[Distutils] Simple idea to resolve versioning problems

[David Cournapeau]

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