If you haven't yet built your project, esy ls-libs fails with an ugly message:
esy ls-libs
esy ls-libs v0.0.66
Couldn't find the binary /Users/me/.esy/3__________________________________________________________________/i/opam__slash__ocamlfind-1.7.3--1-4a313506/bin/ocamlfind
Error: Couldn't find the binary /Users/me/.esy/3__________________________________________________________________/i/opam__slash__ocamlfind-1.7.3--1-4a313506/bin/ocamlfind
at ChildProcess.<anonymous> (/Users/me/.npm-packages/lib/node_modules/esy/bin/esy.js:39179:16)
at emitOne (events.js:116:13)
at ChildProcess.emit (events.js:211:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:196:12)
at onErrorNT (internal/child_process.js:372:16)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
It's understandable that it would fail without ocamlfind, but I think it should just check if ocamlfind is installed, and if not, it could print a nice message saying your project should (depend on ocamlfind, and then be built with esy build).
@jordwalke I'll make sure to include a check that the binary exists.
We already have a check that ensures ocamlfind is in dependencies.
I was under the assumption that BuildTask graph will have all the packages from the config/lockfile, but apparently it only reflects the current node_modules tree.
Thus, I won't be able to distinguish non-existent and simply not built dependencies if my node_modules directory is borked.
@andreypopp I think we should return the check that env is 'healthy' before running sandbox-level commands. (or maybe even mark some commands as needing both install and build)
I was under the assumption that BuildTask graph will have all the packages from the config/lockfile, but apparently it only reflects the current node_modules tree.
Build task graph contains all installed node_modules but packages in node_modules are not necessarily built. We should check at least that ocamlfind is built before we are going to use it.
@andreypopp I think we should return the check that env is 'healthy' before running sandbox-level commands. (or maybe even mark some commands as needing both install and build)
Agree.
This is fixed in 0.1.x. Closing.
I tried on the latest preview and this is the error:
esy ls-libs 0.1.8
esy: internal error, uncaught exception:
Failure("invalid dependency")
This is fixed in master.
On Sun, 11 Mar 2018 at 07:32 Jordan W notifications@github.com wrote:
I tried on the latest preview and this is the error:
esy ls-libs 0.1.8
esy: internal error, uncaught exception:
Failure("invalid dependency")—
You are receiving this because you modified the open/close state.Reply to this email directly, view it on GitHub
https://github.com/esy/esy/issues/136#issuecomment-372088690, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB3gmaUNQsksQOeAWVfpdjSG6MMNTtdks5tdKjBgaJpZM4RvN61
.