Down with PYTHONPATH!

[Ricardo Wurmus]

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
<address@hidden>).
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?

--
Ricardo