Packaging, dependencies and rates of development

[Nick Coghlan]

Bulba! wrote:
> When you have it ALL in the single distro, released from time
> to time, you can easily test it _together_. You don't 
> get _temporal dependencies between various versions_.
> The released, stable distro has the same things on the
> same days, and either it all works together or it doesn't. 

Except that the difference between the distro maintainers' opinion of what is 
"stable enough" for inclusion, and the updated version of that module which has 
some stability problems in areas you don't use but fixes a critical bug in the 
areas you *do* use is always going to be a problem that has to be dealt with.

That's one of the reasons numarray hasn't hit the standard library yet - the 
Python version release and uptake cycle is too slow for the pace of development 
they currently require.

Similarly, this is also part of the reason IDLE went the way of IDLEFork before 
being merged back in 2.3 - the development outside the core tree let Kurt and 
everyone else involved get it up to speed more quickly.

There's also the fact that monolithic approaches just plain don't scale - 
imagining that they can is exactly what leads to the version conflicts that bug 
you so much, since developers assume that they don't need to care about 
versioning issues, because the packagers will take care of them. In reality, all 
it does is move the version conflicts currently noticed by end users and make 
the packagers try to deal with them instead - and for some of the problems, 
side-by-side installation of multiple version is the only solution, and that's 
impossible in the general case without the modules in question providing some 
versioning mechanism. And so, once again, we're left with developers having to 
worry about dependency issues.

For an example of a well-thought out approach to the versioning issue, take a 
look at the work that was done for the recent wxPython release:
http://wiki.wxpython.org/index.cgi/MultiVersionInstalls

What would be ideal is if distutils itself was able to offer a standard package 
versioning system. Then all module developers would have to do is be aware of 
how to use the distutils versioning system, and installing side-by-side versions 
of packages would be create straightforward.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net