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