Re: Down with PYTHONPATH!

[Ricardo Wurmus]

Ludovic Courtès <address@hidden> writes:

>> here’s a half-baked idea that I think is worth considering: let’s patch
>> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
>> our wrappers.
>
> Oh!
>
> [...]
>
>> So I propose to avoid using PYTHONPATH, which is similarly dangerous as
>> LD_LIBRARY_PATH in that it causes incompatible libraries to be loaded.
>> Switching to GUIX_PYTHONPATH is not going to be a complete solution
>> (because it doesn’t distinguish between different versions of Python),
>> but at the very least it will separate Python applications that use Guix
>> from Python applications that don’t.  Right now this is not the case and
>> people who use Guix for some things but not for others have a really bad
>> time and learn to avoid Guix because it sets PYTHONPATH, which breaks
>> their other applications.
>
> The reasoning makes sense to me… but wouldn’t it extend to most of the
> *PATH variables?  After all, PERL5LIB or even GUILE_LOAD_PATH could lead
> to similar issues, no?

Other languages may have similar problems, but I haven’t tested it.

> AIUI, the problem is more acute in Python because of pip, and because
> people are likely to use both pip and Guix, right?

Yes.

>> If we’re feeling lucky we could even introduce GUIX_PYTHON2_PATH and
>> GUIX_PYTHON3_PATH to solve the other half of the problem, namely that
>> Python 2 applications will load Python 3 libraries (and vice versa).
>
> My gut reaction is that this is a problem for upstream to solve
> (GUILE_LOAD_PATH has the same problem, and AFAICS most PATH variables
> are unversioned), but OTOH we’re at the forefront here because we can
> usefully mix Python 2 and Python 3 things in an environment.

Upstream generally doesn’t use PYTHONPATH.  For isolation they use other
mechanism (such as the virtualenv feature), which unfortunately aren’t
flexible enough and thus not applicable for Guix as discussed earlier
based on Hartmut’s analysis.

I think it is a mistake to set these variables globally when they affect
software outside of Guix.  (We have a similar problem with the XDG_*
variables that may suggest to foreign binaries to load incompatible
binaries from Guix, but that’s a different can of worms.)

--
Ricardo