An important prerequisite for this kind of feature would be tracking of a package's files by OPAM, so let's put first things first: if this is indeed important, let's try to give OPAM more control over what is done at installation/removal of packages in the next version.
On the locality of OPAM installations, the more I think about it, the more it seems to me that the best would be to simply allow specifying a custom prefix at switch creation time. All archives, caches and configuration files of OPAM stay in .opam, but packages' installed files, on the other hand, are allowed at a global location, or locally in a subdir of your project. You get the best of both worlds, don't have as much overhead (space, time, network and maintainance wise) as with multiple roots, and npm users aren't too disoriented. We could imagine that, some day in the future, it'll be possible to detect that a package has already been installed in another switch, with the exact same dependencies, and link it rather than rebuild it. That would also make a very cheap "clone switch" feature available. > - Daniel Bünzli, 26/01/2015 22:26 - > Le lundi, 26 janvier 2015 à 21:58, Gabriel Scherer a écrit : > > (Besides compilation time and duplication of efforts -- that could be > > partially solved if/when binary packages where to see the light > > For that I'd rather like to have the ability to install multiple version of a > package in opam. Locally installed packages could then just be hard links to > packages installed in ~/.opam. > > In general, I would also be interested in managing the free variables of my > projects locally. > > Daniel > > > _______________________________________________ > 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
