[Distutils] PEP 376 - RECORD file / Data files + pip feedback ?
Carl Meyer
carl at meyerloewen.net
Fri Feb 5 18:18:17 CET 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi Tarek,
Tarek Ziadé wrote:
> The part that still requires some work is how to handle files prefixes
> in the RECORD file.
>
> Last time we said that we could benefit of having a PREFIXES file.
> Then Wolojda started to work on a much more complete solution to track
> data file locations :
> http://mail.python.org/pipermail/distutils-sig/2009-November/014424.html
[snip]
> But since Pip has now a uninstaller for a few months, the question is:
> what do you Pip guys think about this RECORD file ? (cc'ing Ian as
> well - I know the other involved in that are listening here :))
The prefix stuff in RECORD appears to be new since I last looked at PEP
376, and I don't like it.
If RECORD does not contain absolute paths, it becomes a lot trickier to
use it for uninstallation. In particular if prefix placeholders are
used, it's impossible to uninstall unless we can query for the actual
prefix paths used at install time. And we don't have that unless we
finish Wolodja's work.
If we do finish Wolodja's work, the PREFIXES file will necessarily
contain absolute paths anyway. In which case the installation metadata
is once again not relocatable.
So it seems to me that this idea of a relocatable installation is
inherently incompatible with providing metadata that records the actual
files installed on an actual system. Which is the metadata needed for
uninstall.
Are relocatable installations really all that valuable anyway? What's
the use-case? It seems to me that "move an existing installation" is
something a higher-level tool should worry about (rewriting RECORD in
that case).
I think we should remove all of the relative-path and prefix stuff from
RECORD and go back to requiring absolute paths for all files. This keeps
it simple and obvious, drastically reducing the surface area for bugs.
And that makes it orthogonal to Wolodja's work instead of dependent on
it, so we can go ahead with what we have for 2.7.
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLbFLZFRcxmeyPUXIRAp7gAJ9beyYaNa6fytDihPXJPxTQCkNovwCfdpyu
PA4a2Uzfa0y2g0ieHl835ko=
=SEDF
-----END PGP SIGNATURE-----
More information about the Distutils-SIG
mailing list