[opam-devel] CommonML: An opinionated build/package/develop workflow on top of CommonJS

Anil Madhavapeddy anil at recoil.org
Thu Feb 26 15:19:52 GMT 2015

On 24 Feb 2015, at 08:28, Jordan W <jordojw at gmail.com> wrote:
> Another thing I like about the `CommonJS` workflow is that developing packages locally is virtually the same as developing against remote dependencies. (`npm link` is much like `opam pin` I'm told). When you `npm install` dependencies, everything is pulled down into a local sandbox(node_modules directory) instead of being installed globally by default. If you want to see what versions your local package is seeing, just traverse the file system! If you want to reinstall, just delete the node_modules directory and then `npm install` again. I believe there is a way to get it to use a global package cache so the node_modules might contain symlinks to those shared packages - but that's just an optimization. There isn't any notion of building in `npm`, so there wouldn't be a build cache I believe.

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.

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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150226/68f9c219/attachment.html>

More information about the opam-devel mailing list