On 24 Feb 2015, at 08:28, Jordan W <[email protected]> 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).
-anil
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
