[Catalog-sig] Re: Distutils sprinting at PyCon

[Phillip J. Eby]

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
>don't know.

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
>implementing.
>
>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 
package.

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.)