[Distutils] PEP 376 - RECORD file / Data files + pip feedback ?

Carl Meyer carl at dirtcircle.com
Fri Feb 5 19:39:07 CET 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tarek,

I fully admit that I'm not cognizant of all the internal intricacies of
distutils, in particular the bdist_* stuff, so take my thoughts with a
grain of salt. I just have experience trying to make uninstall work in pip.

Tarek Ziadé wrote:
>> 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.
> 
> This information is given by the location where the egg info resides.
> (sys.prefix/sys.exec_prefix-like)

Presuming the API is now available in distutils for finding PREFIX and
EXEC_PREFIX, given the location of the installed .egg-info, that might
work. But how does this fit with "relocatable"? Doesn't this mean it's
really just "relocatable as long as you're relocating to one of a few
places where distutils expects an installed .egg-info to reside"?

But what about data files? What about all the myriad ways a setup.py
author can munge installation schemes and put things wherever they want?
I already went through the muck once trying to get uninstall working for
the crazy mix of installation schemes we have currently; it's very
unappealing to me to think that relying on complicated prefix-munging is
the best we'll be able to do for uninstall even under PEP 376. I have my
doubts that it will result in reliable uninstall.

> Keeping absolute paths will require extra work in all bdist command because
> those use a local "install --root" called to created an binary tree,
> then copied on the system target
> on installation.
> IOW the RECORD file for them would be inaccurate at installation time.

That is an issue. I can think of two possible solutions, both of which
seem preferable to me to making a mess out of RECORD:

1. Introduce a simple strip filter for adding paths to RECORD that, for
the bdist_* commands, strips the .../build prefix from the paths.

2. Just don't do RECORD for bdist_* at all: if you use bdist_* you're
declaring that you want the target package manager to manage
install/uninstall for you. I have no idea if this meets the needs of all
bdist_* use-cases, but naively it seems to me the whole reason for
bdist_* is because you've got some other package management system
already. Somebody in IRC just said bdist_wininst generates its own
internal record anyway...

> Now for applications, being relocatable
> would be a plus but, the real question I see is: how much pain each
> one of these solutions will be to implement.

I can see the attractiveness of a self-contained, relocatable
installation for applications.

What if RECORD allowed either absolute paths or paths relative to the
location of .egg-info, but nothing else? That would preserve the option
for application authors to make relocatable self-contained
installations, while keeping RECORD simple and useful for uninstall
without relying on prefix-finding magic.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLbGXK1j/fhc23WEARAoFmAKCKilm19hI5YfD8Q7CihDLQDcwXtQCgwczN
DGDlgbfHcUKp/XV93ZnGUVg=
=n9Aw
-----END PGP SIGNATURE-----


More information about the Distutils-SIG mailing list