Absolute path do make some sense in different contexts.
For example a server (system wide installed) as administrator I'm
expecting my config files to be under /etc.
As user ("personal") I'm expecting my config files (for the same
application) could be under ~/.somewhere
A in-between could be the same application to be system wide installed
(*but not configured system wide*) used as user so I'm expecting the
config coming from merged between /etc and ~/.somewhere.
I'm saying this thinking of a unix box, windows pretty much follows the
same pattern, macos is someway different (unles fink/macports aren't
taken into account).
And I'm talking about **applications** (eg. some code + some library
depending on an installed python stack) vs **libraries** (code simply
installed along the current python stack).
So far I haven't seen anything like a graph (uml or just nice) of the
different roles explained and discussed: reason why there've been so
many failures in rewriting distutils in my humble opinion.
*better crawling in the right direction than running in the wrong one*
Antonio
PS. There's a the subtile (but very important) difference between
installation and configuration: so far many fail to see it (until it
bites them).
Paul Moore wrote:
On 4 January 2013 09:37, Chris McDonough<chr...@plope.com> wrote:
I've never really understood the idea that mere installation of a
distribution should need to write to completely arbitrary locations on
>
I agree - on Windows, I would generally consider a package that
installed anything outside of the Python installation to be pretty
much broken (it wouldn't work properly in a virtualenv, for example).
The problem seems to be that Unix/Linux packaging experts seem to have
differing views (in particular around FHS-related concerns). I don't
understand these issues well enough to comment, other than to say that
even among the Unix community there does not seem to be consensus that
there is a need for installation to write outside of site-packages.
I do - very occasionally - take a Python installation and move it (for
example onto a pen drive). It's no longer a "properly installed"
Python, agreed, but for pretty much all practical purposes it still
works and I wouldn't like to see that change as a result of absolute
paths being mandated in a standard.
I'm -1 on absolute paths. Sure, there's an issue with installing files
no locations outside the Python installation, but I'd suggest (1)
deprecating such usage, and (2) using absolute paths there. An
install-time warning might be useful, if it's easy to do. Vinay - does
your analysis of PyPI give any indication of what proportion of
packages actually use the ability to install to arbitrary locations?
I.e., how much of a real world issue is this?
Paul.
_______________________________________________
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
