Pjotr Prins <pjotr.publi...@thebird.nl> writes:
> Then there are people
> using virtualenv on top of Guix ...
Pjotr brings up a good point: can virtualenvs be composed? Do users
still have a way to override modules via PYTHONPATH or some other
mechanism if we were to create virtualenvs by default?
> I think the problem of mixing module versions has to be resolved
> through profiles. That should just work(tm).
@Pjotr: But we have seen that this doesn’t work as is and currently
requires user intervention. We cannot expect users to separate all
Python 2 things from all Python 3 things because it is not even obvious
in all cases that a tool results in Python modules to be installed to
> For this I suggest we tell Python2 to only use PYTHONPATH2. That way
> there is no interference. Python2 is being phased out (it is obsolete)
> and upstream should consider such a solution too.
I’d like to avoid radical patching when Python seems to have some
support for ignoring directories on the PYTHONPATH that don’t include
the correct version number.
Patching Python 2 is still an option, but I’d like to explore (and
understand) upstream mechanisms first.
> With Ruby we have a similar interpreter issue - even more fine grained
> between versions. It is a pain. But there is no real solution other
> than using profiles properly.
Do Ruby *executables* also suffer from accidental dependency injection
as Ribodiff does in this case?
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC