[opam-devel] CommonML: An opinionated build/package/develop workflow on top of CommonJS
anil at recoil.org
Fri Feb 27 09:41:18 GMT 2015
On 27 Feb 2015, at 06:54, Louis Gesbert <louis.gesbert at ocamlpro.com> 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:
More information about the opam-devel