[Python-Dev] PEP 365 (Adding the pkg_resources module)

[Guido van Rossum]

On Tue, Mar 18, 2008 at 11:23 AM, Phillip J. Eby <pje at telecommunity.com> 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/)