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. Cheers, Louis ¹ whatever that could mean nowadays, but you get what I mean. > > The tool is available at https://github.com/avsm/opam-boot > <https://github.com/avsm/opam-boot>. It needs a few more minor improvements > before release, such as depext support and specifying compiler constraints so > that it ensures that the right OCaml version is installed (perhaps via > opam-query). > > -anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
