Hi Lars, Lars-Dominik Braun <l...@6xq.net> writes:
> I think the problem is bigger than usercustomize. Any custom PYTHONPATH > also slips through and causes this issue, as well as any custom > GUIX_PYTHONPATH, because the executable wrapper appends it (think nested > `guix shell` invokations with different versions of a library for > an example where this could go wrong). > > Guix-managed Python packages (libraries nor applications) should > generally not pick up dependencies from random paths – only those > from their package description, so we can keep Guix’ promise of being > self-contained. > > I have experimented with customizing Python’s importing mechanism > through a custom MetaPathFinder. It works by adding a __guix_pythonpath__ > variable to every Python package’s __init__.py file and modifying the > module loader’s search path accordingly if such a variable exists. It > would provide exactly that guarantee, but it’s just a PoC at this > point – see attached file. Woah, looks like a neat solution. Do you think it would scale for all our Python packages without manual intervention? If so, this would definitely be the way forward. > Apart from that I don’t see a good short-term solution right now. It’s > just how Python works. I mostly agree with you, but for this rather common case of having also a usercustomize it would be nice to circumvent it. In general, I don't think we ever want a Guix-produced Python script to load the usercustomize, hence my suggestion. The other case of PYTHONPATH is also annoying but can be tamed by modifying the env variable temporarily. Best, -- Josselin Poiret
signature.asc
Description: PGP signature
