"MvL" == Martin v Loewis firstname.lastname@example.org writes:
>> For cases like the email package or distutils, I think it's >> perfectly OK to only provide the updates for older Python >> releases as separate download. Both have their own way of life, >> so IMHO this is acceptable.
MvL> In neither case, this is really possible: Once you have the MvL> package in the Python core, a separate installation in MvL> site-packages cannot override the core implementation.
MvL> I believe that was the motivation for Barry to consider MvL> backporting large amounts of changes. The same holds for MvL> distutils, except that there aren't that many major changes.
Exactly. For my own purposes (e.g. Mailman) it's no problem; I provide my own email package and arrange for MM to use it before the Python standard one. I actually think it's the right thing for a normal distutils install to not override the standard version.
But I also think there is a use case for allowing a standard package to be separately upgraded for a particular Python installation. As more and more standard Python libraries are packagized, they will probably have life-cycles separate from the Python core themselves (this will only be more true once we evolve toward a CPAN-like arrangement). So I think we will eventually need a way to upgrade (not override :) a standard library package.
My suggestion would be to prepend a new directory on the standard search path, let's call it site-upgrade for now. A normal "python setup.py install" would still install to site-packages, but we'd add a "python setup.py upgrade" command that would install to site-upgrade.