Re: Down with PYTHONPATH!

[Hartmut Goebel <h.goebel@crazy-compilers.com>]

Am 14.06.19 um 10:14 schrieb Ricardo Wurmus:

I welcome your initiative. Fixing this finally is on my todo-list since
long.

> 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).

Rational for GUIX_PYTHONPATH being a cludge (IMHO)

- 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).

- 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).

- If patching getpath.c anyway, we could go for interpreter to determine
the correct "installation path" (see above).

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |