[Python-Dev] Proposing PEP 376

[P.J. Eby]

At 11:51 PM 4/1/2010 +0200, Tarek Ziadé wrote:
>Hello,
>
>On behalf of the distutils-SIG, I'd like to propose PEP 376 for
>inclusion. This PEP is about defining a standard for installed Python
>projects.
>
>http://www.python.org/dev/peps/pep-0376/

Very nice; I have only a few questions/suggestions, and some minor corrections.

First, I notice the RECORD paths are listed as being relative to 
sys.prefix; I was under the impression that these paths were supposed 
to be relative to the base installation location of the library (i.e. 
site-packages in the default case).

That is, that while paths not under sys.prefix were to be absolute, 
the paths under sys.prefix were relative to the install 
location.  (Since one of the original motivating use cases for 
relative paths in RECORD was to support relocatable installations, 
and sharing installations across platforms, when the code is platform 
independent code.)  Also, the spec doesn't address installation to 
paths that aren't under sys.prefix, or what happens if you use 
"setup.py install --prefix".

I'm wondering if perhaps this should be restated as something like:

* Paths under the base installation location are relative to the base
* Paths not under the base installation location, but under the 
installation prefix, are also stored relative to the base, IF the 
base location is a subpath of the installation prefix
* All other paths are absolute.

Where "base location" is the effective --install-lib directory, and 
prefix is the effective --prefix.  (Which default of course to 
site-package and sys.prefix respectively, but the spec shouldn't be 
in terms of those defaults.)

Second, the RECORD spec is not clear on what happens to the hash 
field on .pyc/.pyo files.  Is it supposed to be an empty string, a 
hash of an empty file, a hash value that's ignored, or...?

Third, what is a "local absolute path"?  This term appears several 
places but is not defined.  It sounds like maybe you mean a path 
using the local platform separator, as opposed to a '/'-separated 
relative path.  If that's the case, this should probably be spelled 
out somewhere early on and then referenced in context.

Fourth, the PEP says the implementation will support zipfiles, but 
the draft implementation doesn't appear to support zipimport 
subdirectories.  (Zipimport paths can be /path/to/some.zip/subdir, 
and this base is then used for importing, just as if the zipfile were 
a normal parent directory.)  If this is an intentional omission, it 
should probably be mentioned in the PEP.

Okay, on to the minor corrections.  The following uses of "package" 
should be replaced by "project" or "distribution":

"If a package that was already installed on the system as a dependency"
"in other words, whether the package was installed by user request"
"$ python -m distutils.uninstall packagename"
Anyway, that's my first pass through; I think the RECORD section may 
need further fleshing out (e.g., specifying a particular csv-module 
dialect) in order to ensure that the spec is sufficiently rigorous 
for multiple tools to consume/produce compatible files.