[Distutils] Some clarifications and/or corrections to PEP 376

[Jeroen Dekkers]

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