Hi All, On 13/10/15 01:31, Daniel Bünzli wrote: > Feedback and discussion about the general approach is better done on > this list I think. And this should start with whether the support > should be handled as an inter or intra switch feature; this proposal > being the latter (for these reasons [1]). I know there were attempts > at the former so it would be nice if we could reach consensus on > this first.
A few months ago I started working with Fabrice and Roberto on the extension multi-arch of opam. I started from solver side to tackle this problem, and for the moment I've completely ignored many other details related to the user interface (and specified in your document). I've just committed a working prototype of opam that uses dose to handle multi-arch (or we should say multi-switch) universes and you can find my work here : https://github.com/abate/opam To compile this version of opam you need first to compile and install dose from git [1] . The internal protocol used between opam and dose is described here : https://raw.githubusercontent.com/abate/opam/master/doc/design/multi-switch.txt (clearly the interface between opam and dose does not use the textual form) For the moment the implementation does not do anything more then opam 1.3 : all the changes are transparent to the final user (and I've not widely tested). The idea is to start from here and push upward these modifications and to integrate them to the machinery needed to handle a multi-switch environment. I think the first simple feature I'm going to add is an --upgrade-all option to upgrade all packages of all switches at once (invoking the solver only once). pietro [1]: git clone https://scm.gforge.inria.fr/anonscm/git/dose/dose.git _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
