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

[Phillip J. Eby]

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.