Re: Down with PYTHONPATH!

[Ricardo Wurmus <rekado@elephly.net>]

Hi Hartmut,

>> 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.
>
> I have a *strong* opinion against this, as this would just replace one
> cludge by another one. See below for rational.
>
> IMO the only sustainable solution it to patch the interpreter
> (Modules/getpath.c) to determine the correct "installation path"
> (profile). I did quite some work on this last year, but had no time to
> finish it. I still have no time for finishing, but I should be able to
> hand-over my results (including prepared patches for Python 3.7).

This seems like a much bigger change that would require extensive
testing as it aims to get rid of the wrappers as well.  I welcome a
solution that allows us to ditch the wrappers, but I’d like to fix this
large set of our Python problems soon.

GUIX_PYTHON2PATH / GUIX_PYTHON3PATH is as solution that’s really just a
variant of what we’ve been doing all along (with PYTHONPATH), and it has
precedent in GUIX_LOCPATH, GUIX_GTK2_IM_MODULE_FILE, and
GUIX_GTK3_IM_MODULE_FILE.  It’s a simple solution and removing it later
when a better solution comes along has virtually no costs.

> Rational for GUIX_PYTHONPATH being a cludge (IMHO)

Of course it isn’t pretty.  But introducing it will remove a very real
problem we have.  Installing a package via Guix should not affect other
software that may be available on the system.  Setting PYTHONPATH (to
tell the Guix Python where to find modules the user has installed)
unexpectedly violates this assumption.

GUIX_PYTHONPATH (like GUIX_LOCPATH, GUIX_GTK2_IM_MODULE_FILE and
GUIX_GTK3_IM_MODULE_FILE before it) has the potential to fix this with
relatively little effort.

> - Constraint: We must keep the expected behavior of PYTHONPATH as
> documented for CPython. This esp. means, we must not simply substitute
> in the source PYTHON_PATH by GUIX_PYTHONPATH, but need to *add* code.
>
> - When implementing GUIX_PYTHONPATH in site.py or site-cutomize.py, it
> will fail if python is run using -S (disable the import of the module
> site, and thus site-customize).

I would not implement it there but do it in CPython, copying whatever
code there is for PYTHONPATH and adapt it for GUIX_PYTHONPATH.

> - When implementing GUIX_PYTHONPATH in getpath.c, we need to copy the
> current code for PYTHONPATH, which means we will end up with a not so
> short patch. And even then, this special care needs to be taken to not
> leak GUIX_PYTHONPATH from one profile to the other.
>
> - We still need a wrapper (which caused a lot of problems, we already
> solve. But maybe other problem will arise).

This is a separate problem and it is not a new problem introduced by
GUIX_PYTHONPATH.  We have already simplified the use of wrappers for
scripting languages on core-updates (using a polyglottal Guile wrapper).

--
Ricardo