On Tue, Mar 18, 2008 at 11:23 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote: > >I am hoping that someone will create a simpler bootstrap module that > >is able to download a file of pure Python code and install it, perhaps > >by running its setup.py, assuming that it only depends on distutils > >(or other things previously installed). I will welcome such a module > >into the stdlib. I'm not sure a PEP is even needed, though interested > >parties are certainly welcome to write a PEP specifying the behavior > >first. With 2.6 and 3.0 slated for release in September, there should > >be enough time to get this done before then. > > Unfortunately, as I've already tried to explain, "download a file ... > and install it" is not a sufficiently well-specified requirement to > implement a robust tool. > > Even if it is not to support arbitrary existing distutils sources, > there still needs to be a way to document precisely what the tool > does and does not support installing, so that users can produce > correct files for it to consume, register them properly with PyPI, etc. > > And as I said before (perhaps not very well) the distutils > documentation has already proven to be inadequate as such a > specification, both for users to create these files -- and even more > important -- for programs to consume them. (For example, distutils > source distribution tarball filenames are not unambiguously > machine-parseable.) > > That's why I think some specific "format" (i.e. conventions) have to > be defined for this to work, even if it's merely a set of documented > restrictions on a distutils-based layout, file naming conventions, > versioning, etc. > > In other words, you can't have your cake and eat it, too. If there's > to be a bootstrap tool, you must bless *some* set of packaging > conventions, including file naming, version parsing, and so on. > > Can we use setuptools' version parsing scheme to identify the "latest > stable version", for example? What about setuptools' filename > component canonicalization and escaping rules? > > Frankly, I don't care what the conventions are, only that they be > unambiguously defined and reasonably implementable for producers and > consumers alike. > > I just want there to be *some* sort of robust, documented, standard > installation bootstrap vector in the stdlib, so that setuptools, > zc.buildout, and virtualenv don't have to maintain their own (or > depend on setuptools maintaining its own). > > But not only have you rejected the *only* existing robust and > well-documented conventions for automated processing of Python > libraries, you say you "have no time for this part of the thread" > when I ask what conventions you want to bless *instead*. > > So I'm at a bit of a loss for what we're supposed to do now.
You're welcome to write a PEP as long as it is self-contained (at best referencing other accepted PEPs like the PyPI metadata PEPs). And the PEP better not be 2500 lines long. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
