[Python-Dev] Proposing PEP 376

[Tarek Ziadé]

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