On 27 Feb 2015, at 06:54, Louis Gesbert <[email protected]> wrote: > > Thanks indeed, this is a useful insight in the npm-like workflow and well > worth our attention. > >> I very much enjoyed reading through the CommonML code; thanks for >> documenting it so well! While I digest the rest, I uploaded a simple >> prototype of an `opam-boot` tool that does what you describe above. You can >> just run `opam-boot` in a directory containing an OPAM file, and it will >> take care of the rest via a local .opam installation. This works even if >> OCaml and OPAM are not installed systemwide. > > I have been thinking for a while that allowing to set an arbitrary prefix at > switch creation time could be very useful, and in this case that would allow > an interesting hybrid approach: you would still have a `~/.opam` holding the > repository cache, temporary build directories and that kind of stuff, but you > could create a switch for your project that would hold its binaries in a > sub-directory of your project. Using something like `opam-manager`, that > switch could even be used automatically when running command from within the > project, and we could imagine other tools that facilitate this a lot if it > were to become popular. > > Then I'd also try to be careful on the different mindset we could fine in > compiled vs. interpreted¹ language users: for example, if we provide a > similar workflow to npm with the notable difference that it's much, much > slower (I imagine recompiling OCaml for every project) and space hungry, that > may not ultimately be a huge benefit in terms of image.
I wonder if this is also a way to fold in Gabriel's custom compiler switch mechanism for day-to-day compiler development as well: https://github.com/gasche/opam-compiler-conf -anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
