setup.py: use absolute paths for pth files

[sbraz]

Hi,
On some systems (such as PyPy3 on Gentoo), distutils' data path is not sys.prefix, which means that we cannot rely on relative paths.

[coveralls]

Coverage increased (+2.1%) to 93.659% when pulling 6f566c7 on sbraz:pth into 3935774 on xolox:master.

[coveralls]

Coverage increased (+2.1%) to 93.659% when pulling 6f566c7 on sbraz:pth into 3935774 on xolox:master.

[sbraz]

It looks like older versions of Python should be removed from Travis.

[blueyed]

On some systems (such as PyPy3 on Gentoo), distutils' data path is not sys.prefix, which means that we cannot rely on relative paths.

Can you elaborate on this?
I'm using something similar myself for pdb++: https://github.com/pdbpp/pdbpp/blob/dea1c519f842db114186c42a90c054d958370351/setup.py#L68-L73.

[sbraz]

Hey @blueyed,
On Gentoo, we have this patch which makes distutils install data_files into /usr.

I don't really know why syconfig.py and distutils/command/install.py contain different INSTALL_SCHEMES (links are for CPython but PyPy3's are similar). Because of that, there is no guarantee that distutils's data path will be the same as sysconfig's.

[mgorny]

On some systems (such as PyPy3 on Gentoo), distutils' data path is not sys.prefix, which means that we cannot rely on relative paths.

Can you elaborate on this?

The situation isn't perfect. PyPy is currently designed to rely on sys.prefix pointing to its own install directory, with PyPy-specific subdirectories and all, and that's what you seem to be relying on. However, this breaks a large number of other packages that rely on distutils data install paths being relative to /usr, e.g. to install into /usr/share etc. (using relative paths such as share/pixmaps). This sucks because 1) packages install into wrong paths, and 2) the appropriate files aren't found by system apps/libraries.

While changing this would be possible (and is a worthwhile goal), it requires modifying a lot of PyPy internals (that rely on paths being relative to the executable's realpath). I'm not aware of anyone who has managed that so far. Instead, we do the second best thing possible, i.e. modify distutils to get a correct path set. This means that effectively distutils install paths become disjoint from sys.prefix but so far we haven't had any pain with it. This seems to be the first case of a package that actually relies on distutils data path matching sys.prefix.