Please consider a user scenario quite common: the use of DESTDIR while
planning ahead for path resolution.
Linux distro use DESTDIR (and I believe autoconf-related things) uses
this env variable to set an alternative "root", so:
prefix=/usr
sysconfdir=/etc
DESTDIR=/foo/bar
-> bindir (if DESTDIR is set) = /foo/bar/usr/bin
-> bindir (if DESTDIR is *not* set) = /foo/bar/usr/bin
-> bindir (if DESTDIR is set) = /foo/bar/etc
-> bindir (if DESTDIR is *not* set) = /foo/bar/etc
The make install will write only under DESTDIR not requiring root
permissions (generally regarded as best practice).
Generated rpm can be afterward installed as root (or as required).
Regards,
Antonio
PS. I'm generally against stand alone python "stacks" (isolated
environment) because they're really a bad practice in respect to so many
parameters (especially in highly regulated sectors).
Vinay Sajip wrote:
>
>
>
>> From: PJ Eby<p...@telecommunity.com>
>
>> FWIW, the original reason I argued for relative paths in PEP 376 is
>> supporting installations that are shared across architectures for
>> cross-platform development. At OSAF, it was common to have a single
>> installation directory shared by a Linux, Mac, *and* Windows machine
>> simultaneously. Absolute paths would break in such a scenario, as
>> each accessing machine would see a different absolute path. Some of
>> setuptools' design is specifically mangled to handle this kind of
>> thing.
>
>
> Is this a mainstream use case, though? I'm not dead set against
relative paths, but looking for simplicity if possible. Nowadays the
thinking seems to be around using isolated environments even on a single
platform, rather than trying to share across projects. After all, disk
space is cheap. The other thing is that using *only* relative paths
doesn't cut it - there are circumstances where you write files outside
site-packages, so you would need absolute paths for those files (or
incredibly convoluted relative ones), and that wouldn't work well in the
OSAF scenario you described, anyway.
>
> Regards,
>
Vinay Sajip wrote:
From: PJ Eby<p...@telecommunity.com>
FWIW, the original reason I argued for relative paths in PEP 376 is
supporting installations that are shared across architectures for
cross-platform development. At OSAF, it was common to have a single
installation directory shared by a Linux, Mac, *and* Windows machine
simultaneously. Absolute paths would break in such a scenario, as
each accessing machine would see a different absolute path. Some of
setuptools' design is specifically mangled to handle this kind of
thing.
Is this a mainstream use case, though? I'm not dead set against relative paths,
but looking for simplicity if possible. Nowadays the thinking seems to be
around using isolated environments even on a single platform, rather than
trying to share across projects. After all, disk space is cheap. The other
thing is that using *only* relative paths doesn't cut it - there are
circumstances where you write files outside site-packages, so you would need
absolute paths for those files (or incredibly convoluted relative ones), and
that wouldn't work well in the OSAF scenario you described, anyway.
Regards,
Vinay Sajip
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
