Show HN: Esy – fast and simple package management for native ReasonML/OCaml

I'm one of the developers of esy, would be happy to answer any questions about it.

I have background in JS ecosystem and always liked how npm/yarn allows you to have a set of dependencies installed per project which do not conflict with any other global installations. Then this goes even beyond runtime dependencies and you have tools like eslint/flow and others installed per project in node_modules.

Now enter native development and you won't find the same workflow there. This is what esy tries to solve. It focuses now on Reason programming language but conceptually it works with other platforms/tools too (for example some of our dependencies are C/C++ code and it works nicely with esy too).

Also I want to highlight the following points:

- All dependencies (and devDependencies) are local to a project (like with npm/yarn)

- The cache for built packages is shared between different projects - if you built OCaml 4.06.0 compiler once then the other project will just reuse it (this works similar to Nix package manager)

- To execute some tool within the isolated project environment you prefix it with esy command: "esy ocaml", "esy vim", "esy code"

- esy can install packages from npm, opam (package registry for OCaml ecosystem), github

- esy allows you to develop multiple packages at once (see linking workflow in docs).

- finally... we support Windows (besides Linux and macOS)!

esy can install JS dependencies just fine but we are supporting plug'n'play installations only (see docs https://esy.sh/docs/en/node-compatibility.html for more info on that).

> - On a similar vein, why JSON, and not a config format that supports comments, like TOML?

Yeah, we thought of that but decided to use JSON for now as it's easy to publish esy projects to npm - you already have package.json ready for publish! We might add support for comments to package.json soon though.

> - Will it be able to do Coq projects as well? I've not had a great experience trying to use Opam with it, and had to resort to using submodules. D:

I think it's possible now (I only use it install Coq itself to work through Software Foundations) but I'm not sure about the details yet.

But considering that Coq ecosystem is moving to dune (the build system of choice in OCaml/Reason native ecosystem) and esy supports dune very well I think Coq is going to have a first class treatment soon in esy!

EDIT: re JS compat: you can esy.json instead of package.json and then esy will use it instead. That way you can use package.json with yarn/npm.

If you use js_of_ocaml (a compiler from OCaml/Reason to JS) then esy works with it very well (with the help from dune). With Bucklescript (another OCaml/Reason to JS compiler) it's more complicated (see below).

> With Esy I will be using Dune as my build tool, but instead of the opam binary I can use Esy itself which can pull packages from the opam repository. It takes care of both packages and compiler environment just like opam.

This is correct!

But not necessarily dune (though this is a very good choice), you can use almost any build system you want.

> Is there anything in Esy that would make porting native OCaml packages (like say https://github.com/c-cube/qcheck) to Bucklescript?

Unfortunately not, esy works on level higher than build systems, it doesn't built code itself but rather calls an actual build system to do the workd (dune, make, cmake, ...). Bucklescript is unique as it tries to own the whole stack and thus you have to make code compatible with its build system (bsb) manually.

One thing which esy could help though right now with Bucklescript is providing native tools like ppx'es (preprocessors for Reason and OCaml code) or tools for editors like Merlin (autocompletion and etc.).

> It would also be wonderful to see it in action through a short video tutorial.

Agreed. Hope to have something soon.

Well, Bryan is responsible for the Windows support in esy, not a bit!

- esy builds are happening in an isolated environment with only specified dependencies available

- esy executes build processes under sandboxing (so builds can't write into arbitrary locations, we have some work to do here though)

- esy has feature which allows to rewrite binaries to remove prefix paths from them.

As for package signing+verification (assuming you are talking about source code) we do only integrity checks now for packages downloaded from npm and via opam.

EDIT: wording