Re: Down with PYTHONPATH!

[ng0@n0.is]

Ricardo Wurmus transcribed 2.0K bytes:
> Hi Guix,
> 
> 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.
> 
> PYTHONPATH is dangerously inadequate for use in a wrapper.  Consider the
> case where a user has Numpy installed with Guix but also uses some
> unrelated application that happens to have been installed to
> ~/.local/bin via pip.
> 
> Since numpy is part of the manifest Guix will helpfully record a value
> for PYTHONPATH in etc/profile.  It’s very likely that users rely on
> etc/profile magic to set all needed environment variables, so PYTHONPATH
> will likely be set to a location that makes sense for Python
> applications in Guix.
> 
> The user now runs ~/.local/bin/myapp and the thing crashes because the
> system Python will to load up Numpy from Guix, which is incompatible.
> The system Python may even be Python 2.7.
> 
> PYTHONPATH is the wrong mechanism for Guix to use.  We have previously
> discussed this and Hartmut Goebel analyzed the situation for us in the
> past (see the thread containing the message with ID
> <ad6b1473-2732-ca7b-d971-e548c39013f6@crazy-compilers.com>).
> Unfortunately, we couldn’t decide on a good way forward.
> 
> 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.
> 
> 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).
> 
> What do you think?

Sounds like a reasonable strategy for avoiding mixed python loading,
and the other cases you described above.
 
> --
> Ricardo
>