[Python-Dev] PEP 376 : Changing the .egg-info structure

[P.J. Eby]

At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote:
>Ok I've changed the PEP with all the points you mentioned, if you want
>to take a look.

Some notes:

1. Why ';' separation, instead of tabs as in PEP 262?  Aren't 
semicolons a valid character in filenames?

2. "if the installed file is located in a directory in site-packages" 
should refer not to site-packages but to the directory containing the 
.egg-info directory.

3. get_egg_info_file needs to be specified as using '/'-separated 
paths and converting to OS paths if appropriate.  There's also the 
problem that the mode it opens the file in (binary or text) is unspecified.

4. There should probably be a way to iterate over the projects in a 
directory, since it's otherwise impossible for an installation tool 
to find out what project(s) "own" a file that conflicts with 
something being installed.  Alternatively, reshaping the file API to 
allow querying by path as well as by project might work.

5. If any cache mechanisms are to be used by the API, the API *must* 
make it possible to bypass or explicitly manage that cache, as 
otherwise installation tools and tools that manipulate sys.path at 
runtime may end up using incorrect data.

6. get_files() doesn't document whether the yielded paths are 
absolute or relative, local or cross-platform, etc.


>I need to find back your comments for this part, I must have missed
>them. That's
>the last part I didn't work out yet on the current PEP revision.

Well, if you can't find them, the EggFormats doc explains how these 
file/dir structures are currently laid out by setuptools, 
easy_install, pip, etc., and the PEP should probably reference that.

Technically, this PEP doesn't so much propose a change to the 
EggFormats standard, as simply add a RECORD file to it, and propose 
stdlib support for reading and writing it.  So, the PEP really should 
reference (i.e. link to) the existing standard.  The EggFormats doc 
in turn cites pkg_resources doc for lower-level format issues, such 
as name and version normalization, filename escaping, file parsing, etc.

This PEP should also probably be framed as a replacement for PEP 262, 
proposing to extend the de-facto standard for an installation 
database with uninstall support, and blessing selected portions of 
the de facto standard as an official standard.  (Since that's pretty 
much exactly what it is.)