[opam-devel] One (or more) opam root per projet?

Anil Madhavapeddy anil at recoil.org
Mon Jan 26 21:14:44 GMT 2015


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 <gabriel.scherer at gmail.com> 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
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150126/ca544b3d/attachment.html>


More information about the opam-devel mailing list