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 the profile. > 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? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
