make --set-switch the default in opam env

[Khady]

@Drup wants me to report bad experience that I noticed while using opam2, so here is the first issue. Please let me now if it should be done another way.

I think that --set-switch should be enabled by default when using opam env. My experience is that opam switch set is pretty confusing and should actually be totally avoided. Instead of using it, one should only rely on eval $(opam env --set-switch). It would ensure that the state is per shell rather than global. And the experience would be close to what exist in python.

From discussions on IRC, it seems that even experienced user like @c-cube and @Armael were not aware of --set-switch.

[AltGr]

See #3143 for the discussion that led to this change. In short, it didn't play well with the automatic selection of switch based on $PWD, for the new local switches (which would stop working once OPAMSWITCH has been set, even implicitely)

I agree that possibly having a desynchronisation between the environment as seen by opam (selected switch), and what is currently set in the environment can be annoying ; but, with local switches, setting OPAMSWITCH only makes the problem worse.

The proper solution is to use the shell env-hooks (opam init --enable-shell-hook) that will keep your env in sync as soon as you cd to a local directory. And selecting a given switch for the current shell is just a matter of setting OPAMSWITCH, manually calling opam env is no longer needed.

[AltGr]

Forgot to say, thanks for the feedback!

[Drup]

@AltGr While I understand your point on a fundamental level, the resulting UI is really terrible. I think many people agree that using local switches, either per-directory or per-terminal, is one of the best workflow for using OPAM. I really think the UI should be optimized for that worflow and discourage changing the global switch, which often causes users to have desynchronized envs.

I don't have a concrete advice for crafting a UI that empowers this workflow, but piling additional arguments on operations as fundamental as "Please give me this switch in this terminal" is not great.

[AltGr]

@Drup: but the preferred way is to enable the shell hook, which completely makes the issue go away?

[Drup]

The shell hook is for per-directory switches, but not per-terminal, which are also very useful.

[AltGr]

@Drup: you just need export OPAMSWITCH=foo for per-terminal switches while using the hook.

[Drup]

@AltGr This is not documented and highly non obvious. eval $(opam config --set-sw --sw foo) is already non obvious, messing with env vars directly is somehow even worse. I know opam can do it, I'm just criticizing the whole UI surrounding switch manipulations.

[AltGr]

Agreed on the lack of documentation. The only hint is that eval $(opam env --switch xxx) shows:

[NOTE] To make opam select the switch 4.02.3 in the current shell, add --set-switch or set OPAMSWITCH

but that might go unnoticed, and if the shell hooks have been set, it would be a no-op, so that should in fact be an error. Or magically understood and fixed by opam...

As for exporting a variable, I would argue that, if made clear enough, export OPAMFOO=xxx is not worse than eval $(opam xxx) ; and the intent that it concerns the local shell is made crystal clear.

I would be very interested in better solutions to this if you have suggestions. As mentionned in the issue I linked, eval $(opam env --switch foo) made its way into the habits of many opam users, and is a cool and needed feature, but having it break the automatic selection of switch based on PWD is a problem.

FWIW in my personal habits I have mostly replaced it with the shell hook + path-based switch selection, with local switches or links (using opam switch link). It's quite rare I want to use different switches from the same directory.

I'll keep searching for a solution that works well with local switches and provides a clear interface for shell-based switch selection, whether you are already used to eval $(opam env --switch) or not... but help is welcome if you have ideas!

[Drup]

@AltGr I think we should just try to have a comprehensive "workflow" document that describes what is the preferred opam workflow for working with switchs. Having one would probably make us realize how awkward many of the commands are for this preferred workflow and make everything be more consistent. I agree that the workflow with link is probably the best one, but again, that is barely described.

For instance, opam switch create for non-local switches automatically switch to the new one globally, even though this is probably not what we want in most cases. If global switching is discouraged, we should not make it the default fallback of opam switch FOO. etc.