[Python-Dev] PEP 365 (Adding the pkg_resources module)
Phillip J. Eby
pje at telecommunity.com
Tue Mar 18 17:23:29 CET 2008
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,
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
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.
More information about the Python-Dev