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 | [email protected] | | www.crazy-compilers.com | compilers which you thought are impossible |
