[opam-devel] CommonML: An opinionated build/package/develop workflow on top of CommonJS
louis.gesbert at ocamlpro.com
Fri Feb 27 06:54:20 GMT 2015
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.
¹ 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).
More information about the opam-devel