Hi, I was just trying to implement PEP 376 and saw the same problems. At Thu, 6 Sep 2012 22:33:53 +0100, Paul Moore wrote:
On 6 September 2012 22:18, Daniel Holth <dholth@gmail.com> wrote:
I prefer that paths in record are always relative to the parent directory of record (usually site-packages) unless a relative path would not work (drive letter boundaries). Consider installing and then chroot.
That's a much simpler rule and I agree in principle that it's preferable. The problems are:
1. It's much further away from what PEP 376 specifies. I will accept this happily if there is general agreement that it's OK, but I preferred to start with a more conservative suggestion :-)
What PEP 376 currently specifies doesn't really work (or I don't understand it correctly). It specifies that the .dist-info directory should be installed in site-packages, but the file paths in RECORD are relative to the "base location". The "base location" is defined by the --install-lib option that only defaults to the site-packages directory. So if I change the "base location" to be something else using --install-lib the file paths in RECORD will be relative to that directory (if it's also under prefix), but there is no way to figure out what the directory is from the information in the .dist-info directory. The example RECORD file in PEP 376 also seems wrong to me, because the paths look relative to sys.prefix instead of relative to site-packages directory (and the docutils-0.5.dist-info is also missing a lib/). The example of dist.get_installed_files that is supposed to return the contents of RECORD also shows different paths than the first example, but those are also not relative to the site-packages directory. I agree that having the paths relative to the parent directory of the .dist-info directory is preferable. It's easy to implement and I don't really see any downsides at the moment.
2. Do you really want long strings of ../../.. if a distribution specifies a file to be installed in an absolute location (possible, although probably not well supported by current tools). Consider a package that installs something to /var/python (I'm not a Unix user, so this may be an unconvincing example, but I understand that similar things *are* possible). If Python is in /usr, you'd have RECORD with something like ../../../../var/python. I don't have enough Unix experience to know if anyone would care about this. Of course what I know about chroot implies this would break in that scenario anyway...
As I say, if the Unix people are OK with it, I'm happy to go this way.
I think it is very rare that a distribution would need to install to an absolute path. What might be more common is having to refer to the /usr/lib and /usr/bin directories from /usr/share, but I don't see any problems with using relative paths for that.
Of course, I'd be happy to mandate that files in a distribution should never be installed anywhere that isn't defined as one of the sysconfig defined paths - but suggesting that would be sure to start a much bigger debate that I don't want to get into as I don't have the expertise to referee it.
I think it's a pretty good suggestion to have packages only install files in a set of predefined locations, but we would have to make sure that all cases are covered by the sysconfig defined paths. Support for things like manpages seem to be missing for example. Kind regards, Jeroen Dekkers