
Show HN: Esy – fast and simple package management for native ReasonML/OCaml - andreypopp
https://esy.sh
======
andreypopp
Hi,

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

~~~
jasim
Hi Andrey, can you tell me if this understanding is correct - ? I can use Esy
to write native OCaml/Reason, but has no use in a compile-to-js environment -
there it is npm/yarn. 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.

The `link` directive is much more ergonomic than `npm link`. Nice.

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

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

~~~
andreypopp
> I can use Esy to write native OCaml/Reason, but has no use in a compile-to-
> js environment - there it is npm/yarn.

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](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.

------
bryanphe
Just wanted to say thank you for all your work on this, Andrey!

I've been using for developing native projects with ReasonML / OCaml (on
Windows!) - a framework called Revery [1] (a fast, native alternative to
Electron) and a re-write for our Oni [2] text editor using this platform. It
really wouldn't have been possible to pursue these paths without esy.

We're also starting to see other cross-platform Reason-native projects pop-up
that I'm very excited about, like Brisk (native OSX UI w/ Reason/OCaml) [3]
and Fastpack (native JS bundler - a faster webpack) [4].

Some of my favorite features are the following:

\- Esy gives the convenience of NPM / Yarn, but for native development.
Importantly, it _works great cross-platform_ \- OSX/Linux/Windows. IMO The
ease of cross-platform development is one of the JS+Node+NPM workflows
greatest strengths, and esy provides this for native development.

\- Esy gets faster as you use it. It has smart caching for compiled artifacts
- taking into account the full set of transitive dependencies.

\- The linking / resolution workflow is incredibly useful for native
development. For Revery, we'd often need to try fixes across our GLFW/Fontkit
stack, and the link feature made this simple.

I'm biased as I've contributed a little bit to the esy, but I've found the
approach to development really interesting architecturally - esy is like a
'React' for dependency management - treating the dependency tree as a "pure
function" of (dependency tree -> lock -> build environment) with "memoization"
to re-use compiled artifacts.

These are tough problems to solve in native... and I'm really impressed with
your work Andrey! Thank you!

\- [1] [https://github.com/revery-ui/revery](https://github.com/revery-
ui/revery)

\- [2] [https://github.com/onivim/oni](https://github.com/onivim/oni)

\- [3] [https://github.com/briskml/brisk](https://github.com/briskml/brisk)

\- [4]
[https://github.com/fastpack/fastpack](https://github.com/fastpack/fastpack)

~~~
andreypopp
> I'm biased as I've contributed a little bit to the esy,

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

------
e12e
This looks very nice! I wonder if it might be easy(ish) to wrap it as a plug-
in for asdf? There's already an opam/ocaml plug-in - but from comments here it
sounds like it might be possible to write a wrapper similar to the ruby plug-
in that re-uses a lot of the tooling for rbenv/build. (as does the rust plug-
in, and others)

[https://github.com/asdf-vm/asdf](https://github.com/asdf-vm/asdf)

------
Foxboron
I'm having a hard time figuring out if esy supports reproducable builds, and
package signing+verfication.

And if reproducable builds are supported, what format is used to store the
build information so downloaded packages can be reproduced.

~~~
andreypopp
esy tries hard to enable reproducible builds:

\- 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

~~~
Foxboron
And how is the build env recorded for timestamps and env variables? Is all of
this standardized?

>we do only integrity checks now for packages downloaded from npm and via opam

Which is fine, but esy should be capable of accepting signatures and checking
them against a given key.

~~~
andreypopp
> And how is the build env recorded for timestamps and env variables? Is all
> of this standardized?

We do record the build env now in esy's own format, you run:

    
    
        esy build-plan PKG
    

to see the build plan (a-la Nix derivation) which is a JSON with build
commands and environment.

As regarding timestamps we don't set SOURCE_DATE_EPOCH yet but we definitely
plan to address that.

