install python module to site-dir (ROOT-3316)

[xantares]

This patch installs python modules to python site-dir standard location (see some doc here:https://docs.python.org/2/library/site.html), see https://sft.its.cern.ch/jira/browse/ROOT-3316

It avoids to have to set PYTHONPATH when installing to a system folder /usr or /usr/local, and even the user site-dir ~/.local

Packaging may have to be reworked though (https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-paths)

[xantares]

hi @karies, @peremato, someone up for a review ?

[Axel-Naumann]

@wlav should have a look as he seemed to have good reasons against such a change on https://sft.its.cern.ch/jira/browse/ROOT-3316.

[wlav]

Hi,

yes, my objections are all documented in that jira report. I strongly
vote 'no'. If anyone wants to go ahead anyway, then sign a contract in
blood that you'll maintain it and help confused users from here on out.

Best regards,
Wim

On Thursday 2015-09-03 05:08, Axel Naumann wrote:

Date: Thu, 03 Sep 2015 05:08:04 -0700
From: Axel Naumann notifications@github.com
Reply-To: root-mirror/root
<reply+00613b66d70f8ce7beaed1a94ac44c0adf0329085ffc340492cf0000000111fffa2
492a169ce05d53aeb@reply.github.com>
To: root-mirror/root root@noreply.github.com
Cc: wlav WLavrijsen@lbl.gov
Subject: Re: [root] install python module to site-dir (ROOT-3316) (#73)

@wlav should have a look as seemed to have good reasons against such a change on https://sft.its.cern.ch/jira/browse/ROOT-3316.

---

Reply to this email directly or view it on GitHub:
#73 (comment)

WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net

[xantares]

hello @wlav,

I was confused to have to set PYTHONPATH in the first place, like Andy was :)

Forgive me but your objections do not seem rock-solid:

• '"distutils.sysconfig" is far from robust as claimed' : afaik it works very well from 2.6-2.7, 3.1,3.2, 3.3 to 3.4
• "package as a whole gets split, which risks that one part gets updated whereas another doesn't": how would that be possible for users ? a decent package manager should handle that well

regards

[wlav]

Hi,

On Thursday 2015-09-03 10:56, xantares wrote:

Forgive me but your objections do not seem rock-solid:

• '"distutils.sysconfig" is far from robust as claimed' : afaik it
  works very well from 2.6-2.7, 3.1,3.2, 3.3 to 3.4

sure, on Linux. Did you try all main platforms? (And do add at least p2.5,
as that for sure is still in use.)

• "package as a whole gets split, which risks that one part gets updated
  whereas another doesn't": how would that be possible for users ? a
  decent package manager should handle that well

A package manager can install wherever it wants and can make its own
adjustment (simply copy over the two files, or put symlinks); this will
affect users building from source. I don't worry about package managers,
only about the latter users. As to 'how': the common case mixing
installations (e.g. from packagers and building from source), versions
(different pythons), system upgrades (that wipe out site-packages), or
simply a user doing 'rm -rf' for only half the installation. Users are
very, very inventive in creating trouble. :P None of that if all of ROOT
is kept in a single directory.

So the only upside there seems to be is removing of this teeny-weeny
inconvenience of having to setup PYTHONPATH if you install in /usr/local.
But A) most from-source builders don't do that, they use bin/thisroot.sh,
which sets up PYTHONPATH; and B) installing in /usr/local is not
recommended to begin with, b/c of the same problem with remnants.

Debugging a setup problem is very time consuming and frustrating: the
error messages are spurious and only occur on the user's machine to which
I have no access.

In sum, I see no upside to speak of, but do see enormous downsides. And
if you really believe otherwise: sign that blood contract.

Best regards,

Wim

WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net

[xantares]

@wlav
"So the only upside there seems to be is removing of this teeny-weeny inconvenience of having to setup PYTHONPATH if you install in /usr/local. But A) most from-source builders don't do that, they use bin/thisroot.sh, which sets up PYTHONPATH; and B) installing in /usr/local is not recommended to begin with, b/c of the same problem with remnants."

A) it's also valid when installing as user to ~/.local (like when you install a python module with --user)
B) of course, users shouldn't install anything to /usr[/local] without using package management, but it will simplify packaging too by not having to install an ugly script somewhere that sets PYTHONPATH

As for the downsides, I think this solution is just simpler (not mentioning cleaner), maybe this will get you less bug reports.

[wlav]

Hi,

very last time and then I give up ...

B) of course, users shouldn't install anything to /usr[/local] without
using package management

But they do.

but it will simplify packaging too by not having to install an ugly
script somewhere that sets PYTHONPATH

Ugly scripts that are seldom seen. I care more about humans than computers.
Additionally, the removal scripts can be simpler, as the package manager
knows where it put what, rather than the package stuffing portions in
different places, so I'd say its a wash.

As for the downsides, I think this solution is just simpler (not
mentioning cleaner), maybe this will get you less bug reports.

Straight of the bat, the whole nightly build system would roll over and
all developers that use cmake (not me, luckily) would have to change their
workflow. Why? B/c most of these setups are 1 python installation and
multiple ROOT installations, or different users for both so no access
rights to site packages. Add that packagers for LCG experiments now need
to know that ROOT puts stuff in $ROOTSYS and in $PYTHONHOME and fix what
they pick up from where. For that matter, I think there will be far more
'ugly scripts' being created here to work around the mess this would add,
that I dare claim that even that argument of yours holds no water.

Like I said, this is my last word on it. It's not worth my time if you
refuse to look beyond that one use case.

Best regards,

Wim

WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net