global switch remains in PATH when local switch is activated

[RalfJung]

When I cd to a directory containing a local opam switch (a _opam directory), my PATH looks as follows:

/home/r/Dokumente/Unisachen/iris/coq/_opam/bin:/home/r/.opam/system/bin:/home/r/bin:/home/r/.cargo/bin:/home/r/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Notice now the global "system" switch is in the path even though that switch is not even active! That should not happen, right?

I have the following in my ~/.profile:

# set up OPAM
opam switch system # reset default switch in case I accidentally changed it
test -r /home/r/.opam/opam-init/init.sh && . /home/r/.opam/opam-init/init.sh > /dev/null 2> /dev/null || true
unset MANPATH # unbreak man

And in my ~/.bashrc:

# set up OPAM -- needed to get the right local switch when bash is started
test -r /home/r/.opam/opam-init/init.sh && . /home/r/.opam/opam-init/init.sh > /dev/null 2> /dev/null || true
unset MANPATH # unbreak man

# opam config report
# opam-version      2.0.7 
# self-upgrade      no
# system            arch=x86_64 os=linux os-distribution=debian os-version=testing
# solver            builtin-mccs+glpk
# install-criteria  -removed,-count[version-lag,request],-count[version-lag,changed],-changed
# upgrade-criteria  -removed,-count[version-lag,solution],-new
# jobs              8
# repositories      4 (http), 3 (local), 2 (version-controlled) (default repo at ff95b837)
# pinned            4 (rsync)
# current-switch    /home/r/Dokumente/Unisachen/iris/coq

[AltGr]

That's not expected to happen; the mechanism opam uses to revert its previous changes is to lookup the OPAM_SWITCH_PREFIX variable, read the file .opam-switch/environment below it, and "undo" that (on a best-effort basis) before applying the changes for the new switch.

Maybe something interfered with one of the two ? You could check by running opam env --revert.

[RalfJung]

opam env --revert prints

$ opam env --revert
OPAM_SWITCH_PREFIX=''; export OPAM_SWITCH_PREFIX;
CAML_LD_LIBRARY_PATH=''; export CAML_LD_LIBRARY_PATH;
OCAML_TOPLEVEL_PATH=''; export OCAML_TOPLEVEL_PATH;
MANPATH=''; export MANPATH;
PATH='/home/r/.opam/system/bin:/home/r/bin:/home/r/.cargo/bin:/home/r/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games'; export PATH;

[RalfJung]

Possibly the problem is related to sourcing /home/r/.opam/opam-init/init.sh in both .profile and .bashrc? The issue is that PATH adjustments need to be in .profile or else they won't take effect for the graphical Desktop Environment, but opam's cd hook needs to be in .bashrc (potentially related to #4201).

[RalfJung]

Yeah, removing the .profile part of this fixed the problem. I don't currently have any GUI applications installed with opam so this works as a work-around, I guess.

[kit-ty-kate]

I seem to have a similar issue probably due to the fact that I enter my Wayland session via a terminal which already sets the PATH via the opam script, so the original switch is always kept.

[dra27]

Discussed today: sourcing variables.sh has the benefit of being fast, but not idempotent. Idea instead is to detect if OPAM_SWITCH_PREFIX is set and in this case to eval $(opam env --revert) and then source variables.sh as normal. So the "normal" path is fast and just sources the file and only in the slightly less common case here does opam get called to update the environment.