The major difference between switch and roots is that remotes are shared across switches. Pins are already per-switch.
There's a good case to be made for a per-project OPAM installation, especially for OCaml applications that just want to build a binary with the minimum hassle (such as Facebook's Flow static analyser). See here for a discussion on the topic: https://github.com/ocaml/opam/issues/1372 <https://github.com/ocaml/opam/issues/1372> I'd quite like to see an `opam-local` script as discussed in that issue. It should be a lot easier now that OPAM 1.2 has been released. -anil > On 26 Jan 2015, at 20:58, Gabriel Scherer <[email protected]> wrote: > > Dear opam-devel, > > Guillaume Claret (one of the Coq developpers) has been experimenting with > using one OPAM root for each of his software projects, instead of using > global switches. > > http://coq-blog.clarus.me/use-opam-for-coq.html > <http://coq-blog.clarus.me/use-opam-for-coq.html> > > I have a personal preference for keeping using switches that I'm familiar > with and seem more idiomatic in OCaml usage (and also compiling Coq in each > project would remind me too much of my Gentoo years), but Guillaume points > out that it has evolved to be standard usage in the Node/npm community (and > with Python/virtualenv I think), and that it can solve incompatible-version > headaches by having a finer granularity. More generally the rationale seems > to be "local is better than global", which sounds reasonable. > > (Besides compilation time and duplication of efforts -- that could be > partially solved if/when binary packages where to see the light -- a good > argument in favor of switches would be the ability to install programs across > multiple switches in the same root, eg. opam compiler-conf and similiar > scripts.) > > Do you know of other users having converged towards that per-project scheme? > Is there tool support, or interest in eventually supporting, for this mode of > use in upstream OPAM? > _______________________________________________ > opam-devel mailing list > [email protected] > http://lists.ocaml.org/listinfo/opam-devel
_______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
