[Python-Dev] Proposing PEP 376 (original) (raw)

P.J. Eby pje at telecommunity.com
Fri Apr 2 01:36:53 CEST 2010

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:

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.

More information about the Python-Dev mailing list