<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The major difference between switch and roots is that remotes are shared across switches. Pins are already per-switch.<div class=""><br class=""></div><div class="">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:</div><div class=""><a href="https://github.com/ocaml/opam/issues/1372" class="">https://github.com/ocaml/opam/issues/1372</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-anil</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Jan 2015, at 20:58, Gabriel Scherer <<a href="mailto:gabriel.scherer@gmail.com" class="">gabriel.scherer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Dear opam-devel,<br class=""><br class="">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.<br class=""><br class=""> <a href="http://coq-blog.clarus.me/use-opam-for-coq.html" class="">http://coq-blog.clarus.me/use-opam-for-coq.html</a><br class=""><br class=""></div>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.<br class=""><br class=""></div><div class="">(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.)<br class=""><br class=""></div><div class="">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?<br class=""></div></div>
_______________________________________________<br class="">opam-devel mailing list<br class=""><a href="mailto:opam-devel@lists.ocaml.org" class="">opam-devel@lists.ocaml.org</a><br class="">http://lists.ocaml.org/listinfo/opam-devel<br class=""></div></blockquote></div><br class=""></div></body></html>