2010/4/2 P.J. Eby <p...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
