Recently, I upgraded from OCaml 4.11 to 4.14, though not intentionally (an error message suggested that I use the --unlock-base option on some opam install, so I did that without worrying much about the possible consequences, naively thinking that whatever changes would only concern the package I was installing. I was wrong : now, lo and behold, my whole system is upgraded to OCaml 4.14).
I had a switch named “4.11.0” after the OCaml version, and I noticed that all the OCaml-related tools in ~/.opam/4.11.0/bin were in fact now using the 4.14 version, so I renamed the 4.11.0 subdirectory to 4.14.0, and similarly I edited the ~/.opam/config file to replace all occurrences of 4.11.0 by 4.14.0.
Most of the things work ; thus if I launch utop it uses a 4.14 compiler, I was successfully able to recompile all my projects using the 4.14 version, etc.
But there are still a few problems left. Notably, the output of opam env is incorrect, mixing some references to 4.11.0 to 4.14.0. This is probably the reason why, when I launch VSCode, it complains that it can’t find ocamlmerlin.
I thought of that. But I actually found a compromise more suited to my situation.
I renamed the ~/.opam/4.14.0 to ~/.opam/corrupt_switch, then proceeded to recreate a clean switch from scratch, with opam switch create 4.14.0 4.14.0, opam switch set 4.14.0, and reinstall everything I need.
The reason I’m proceeding like this is because I can now switch to corrupt_switch when I need the pfff package. I realized that the pfff package is somewhat “toxic” and that it can’t be installed normally along with the most recent ocaml packages. In fact, opam install pfff only works when the OCaml version is < 4.12, otherwise it will issue an error message suggesting the use of --unlock-base, and this --unlock-base is what triggered all this mess in my opam configuration in the first place.
It seems good practice to keep problematic, in-development packages in their own separate switches, so they don’t corrupt the rest.