> - Peter Zotov, 21/12/2014 19:20 - > On 2014-12-21 19:16, Daniel Bünzli wrote: > > Le dimanche, 21 décembre 2014 à 16:57, Peter Zotov a écrit : > > > >> I still don't see a reason to have multiple versions installed at once > >> that would justify the migration cost. > > > > You may be working on different projects whose recursive dependencies > > includes two different versions of a library or you are a library > > author working on an incompatible release of a library. Both already > > happened to me and it's painful. Using a switch just for that as it > > was once suggested to me is painful and error prone, one time out of > > two you end up starting your build in the wrong switch. > > How about having your shell change the switch based on e.g. > `.opamswitch` > file in the project root? I actually want this supported regardless, it > would be very convenient. >
That's exactly what 'opam-manager' [1] provides ; also, still error-prone, but you can always set a switch in a given shell instance using `eval $(opam config env --switch <switch>)` as mentionned in the FAQ [2] ; I recenlty improved `opam switch` to be much more helpful when you are not in the standard situation. I agree with Daniel that switches may not be the best solution -- but I am afraid that opening this door is a very bad idea until build and link tools more widely support it. > - Daniel Bünzli, 21/12/2014 17:58 - > That being said it would be interesting to have a clear definition of what a > switch is (or will be) in opam, especially in the light of compilers as > packages, per switch opam repositories, multi-switch packages, globally > pinned packages, and what not. As I understand it at the moment, a switch is defined by a `.comp` file: this is basically just a set of "base" (e.g. immovable) packages that get installed at creation (we can now count the compiler as one of them). Then, as for the `opam switch` command, a switch is - a prefix, and the associated set of environment variables - a set of installed packages - a set of pinned packages and their definitions Now, we have built on this quite strong basis for a while with success, so I agree with Daniel that we must be very careful and specify precisely what will be going on before we start breaking the wall between switches -- or even moving more stuff inside them, as with per-switch remotes. [1] https://github.com/hnrgrgr/opam-manager/ [2] http://opam.ocaml.org/doc/FAQ.html#CanIworkondifferentswitchesatthesametimeindifferentshells _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
