Re: Anomalies in Python search-path

[ludo@gnu.org (Ludovic Courtès)]

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 15.01.2017 um 23:10 schrieb Ludovic Courtès:
>>> > My last reporting that pip was working correctly in non-environment was
>>> > wrong because I had failed to logout/login after installing the python
>>> > package; after doing so, the behavior is the same as in an environment:
>>> > the user site location (~/.local/...) comes after site-packages rather
>>> > than before, as would normally be the case. Apparently this is due to
>>> > setting a site-packages location with the environment variable
>>> > PYTHONPATH, which has precedence over the user site location.
>> ~/.guix-profile/etc/profile prepends things to the search paths, but
>> it’s up to the user whether to source it before or after other
>> definitions have been provided (in .bash_profile or similar).
>
> Maxim is talking about how python is processing the paths.
>
> The "normal" order is:
> - $PYTHONPATH  (which normaly does not include site-packages)
> - Python Standard library (not including site-packages)
> - user's site-packages (~/.local/lib/python3.4/site-packages)
> - global site-packages (/usr/lib/python3.4/site-packages)
>
> The user's site-packages take precedence over the global ones.
>
> In Guix we currently use PYTHONPATH to add global site-packages. Since
> PYTHONPATH parts are put in front of the search list, they take
> precedence over the user's site-packages. And this behaviour is wrong.

Oh, I see.

I’m not sure what can be done on our side.  PYTHONPATH is the only thing
we can influence.

It looks like the notion of “global site-packages” only applies to FHS
systems and makes little sense for us.  If there were, say, a
PYTHONSITEPATH in lieu of this “global site-packages” thing, we could
use that.

Ludo’.