[opam-devel] OPAM Roadmap -- what next ?

Louis Gesbert louis.gesbert at ocamlpro.com
Mon Dec 22 02:32:57 GMT 2014

> - 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

More information about the opam-devel mailing list