[Catalog-sig] Re: Distutils sprinting at PyCon
Phillip J. Eby
pje at telecommunity.com
Mon Jan 31 22:04:39 CET 2005
At 07:40 AM 2/1/05 +1100, Richard Jones wrote:
>[this is a response to a comment PJE left in my weblog]
>On Tue, 1 Feb 2005 03:56 am, Phillip J. Eby wrote:
> > we're working on ... http://peak.telecommunity.com/DevCenter/PythonEggs
> > ...
> > This format would obsolete PEP 262, since removing a package will be a
> > matter of just deleting its .egg file. It affects PEP 314 too, because
> > "download URL" doesn't allow for platform-specific binary distribution like
> > .egg files, and because better platform information is needed.
>I'm not sure that having download URLs for *every* download format is *sane*
>for having in the PKG-INFO.
I agree. The idea Bob and I are working on is that the download URL is in
fact the URL of a manifest file that lists platforms and download locations.
>The current bdist commands don't modify PKG-INFO
>though, which shoots this idea down pretty quickly (the platform information
>would need to be changed also).
Exactly; platform-specific info shouldn't be in PKG-INFO.
> There may be some crossover with EGG-INFO, I
The EGG-INFO directory is wide open for extension with additional metadata
files; currently we only have two files in EGG-INFO whose contents are
defined: native_libs.txt and eager_resources.txt. These control automatic
extraction of files when other files are requested for extraction. I would
suggest that a (non-platform-specific) PKG-INFO might be useful to include
in the EGG-INFO directory.
>How to then handle a collection of download URLs is another problem. It could
>partly be solved by an online repository of the sort I'm planning on
>This problem has had a lot of hand-waving up until now ;)
We're trying to do something along the lines of Eclipse's "feature"
concept, where a file describes a feature (package in this case) and lists
the various downloads that are required for that feature including
platform-specific URLs for those items that are platform-specific.
The idea is that the download URL in PyPI and elsewhere would then be the
download URL for a file that describes currently available versions of the
Obviously there is still some handwaving here, but hopefully the waves are
much smaller and better defined now, because it's more about defining a
format and having tools to parse and download.
(We may want that file to be XML, simply because it would allow the
contents to be rendered with an XSL stylesheet for viewing by humans.)
More information about the Catalog-sig