I wonder if decoupling more of the standard library isn't a good idea, although it flies in the face of "batteries included". One thing I
I'd like this approach, though perhaps the "Batteries Included" distribution rather than the standard library should be handled like this.
For a batteries included release, this would be great.
It would also require finalizing a catalog implementation (at last!)
I believe Kapil is working on it; he's presenting a paper at OSCON2002.
An open question is how to avoid the CPAN trap of having your modules require you to upgrade your Python installation. Perhaps each module version would specify the Python version it's compatible with.
Module version compat. with 0.0.1 Py2.1 0.0.2 Py2.1 0.0.5 Py2.2
Ideally it should list a range of versions (or a set?). Of course, the upper end of the range may need to be adjusted when new releases come out -- nobody knows whether Module 0.0.5 will be compatible with Py2.3 until the latter is released.
So when you're on Python 2.1, you can only get upgraded to 0.0.2. The problem is, if the developer of version 0.0.5 didn't realize that it was incompatible with 2.1, you'll get upgraded to it and your system will be broken.
(Take package management far enough and you begin to reinvent Debian's APT. I wonder if we could write a dpkg-like tool in Python and then just use APT on top of that?)
I think version dependency management is subject to the Logajan paradox. :-(
--Guido van Rossum (home page: http://www.python.org/~guido/)