There seems to be a misunderstanding about what I am proposing we do instead. The boostrap installer should only be powerful enough to allow it to be used to install a real package manager like setuptools. Maybe my use of Django as an example was confusing; I didn't actually mean that it should be possible to support installing Django directly (although I don't understand all the issure that would make it impossible). Only very few people would care about writing a setup script that works with this bootstrap module; basically only package manager implementers. --Guido On Tue, Mar 18, 2008 at 3:45 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Guido van Rossum writes:
I am hoping that someone will create a simpler bootstrap module
FWIW (I've never tried to implement one of these things) I agree with Phillip. This is not possible in the sense you are advocating. Anything "simpler" is simply an invitation to an unending stream of issues, far more so than adopting eggs as a best current practice would. Better to Just Say No to an installer in the stdlib.
I'm not sure a PEP is even needed
This I simply don't understand. I *have* participated in bolting on features to such systems, and it's a mess. As features are added, existing users will demand that old packages install exactly as they ever did, except that sometimes (but not always!) they want them upgraded to put things in newly blessed places. Features are easy to add, since on the main thread of control installers are basically just a sequence of single commands, sometimes optional.
python-dev has some pretty good controls that will help slow such trends. Nonetheless, PEP-less development of an installer system is scary. Installer complexity is a creeping horror, worse than kudzu.[1]
Footnotes: [1] http://en.wikipedia.org/wiki/Kudzu#Invasive_species
-- --Guido van Rossum (home page: http://www.python.org/~guido/)