Hi,<p>I'm one of the developers of esy, would be happy to answer any questions about it.<p>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.<p>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).<p>Also I want to highlight the following points:<p>- All dependencies (and devDependencies) are local to a project (like with npm/yarn)<p>- 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)<p>- To execute some tool within the isolated project environment you prefix it with esy command: "esy ocaml", "esy vim", "esy code"<p>- esy can install packages from npm, opam (package registry for OCaml ecosystem), github<p>- esy allows you to develop multiple packages at once (see linking workflow in docs).<p>- finally... we support Windows (besides Linux and macOS)!
Just wanted to say thank you for all your work on this, Andrey!<p>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.<p>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].<p>Some of my favorite features are the following:<p>- Esy gives the convenience of NPM / Yarn, but for native development. Importantly, it <i>works great cross-platform</i> - 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.<p>- Esy gets faster as you use it. It has smart caching for compiled artifacts - taking into account the full set of transitive dependencies.<p>- 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.<p>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.<p>These are tough problems to solve in native... and I'm really impressed with your work Andrey! Thank you!<p>- [1] <a href="https://github.com/revery-ui/revery" rel="nofollow">https://github.com/revery-ui/revery</a><p>- [2] <a href="https://github.com/onivim/oni" rel="nofollow">https://github.com/onivim/oni</a><p>- [3] <a href="https://github.com/briskml/brisk" rel="nofollow">https://github.com/briskml/brisk</a><p>- [4] <a href="https://github.com/fastpack/fastpack" rel="nofollow">https://github.com/fastpack/fastpack</a>
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)<p><a href="https://github.com/asdf-vm/asdf" rel="nofollow">https://github.com/asdf-vm/asdf</a>
I'm having a hard time figuring out if esy supports reproducable builds, and package signing+verfication.<p>And if reproducable builds are supported, what format is used to store the build information so downloaded packages can be reproduced.