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

Tarek Ziadé ziade.tarek at gmail.com
Sun Apr 4 00:48:56 CEST 2010

2010/4/2 P.J. Eby <pje at telecommunity.com>: [..]

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

Sounds like a better solution.

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

The example misses pyc/pyo files. Those would have no hash, and I also think the size should be omited as well.

I'll update the example.

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.

Yes, this is it. It was defined somewhere but removed at some point by mistake IIRC. I'll add that

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.

The implementation so far will load zip files founded in the paths, see ZippedDistributionDir/ZippedDistribution.

I am wondering though, if we shouldn't omit this zip story for PEP 376 altogether, and work later on something more generic wrt import protocols where modules/packages could be stored anywhere.

IOW, PEP 376 could focus exclusively on a pure filesystem site-packages.

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"

yes, will edit this.

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.

Yes, and we should list those tools somewhere in the PEP I guess

Regards Tarek

-- Tarek Ziadé | http://ziade.org

More information about the Python-Dev mailing list