Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
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.
On Tue, Mar 18, 2008 at 11:23 AM, 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.
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/)
participants (2)
-
Guido van Rossum -
Phillip J. Eby