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?


GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC

Reply via email to