esy ls-libs fails if not yet built.

Created on 27 Jan 2018  Â·  7Comments  Â·  Source: esy/esy

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

bug

All 7 comments

@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
.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lessp picture lessp  Â·  7Comments

jaredly picture jaredly  Â·  7Comments

zartstrom picture zartstrom  Â·  3Comments

smorimoto picture smorimoto  Â·  3Comments

jordwalke picture jordwalke  Â·  5Comments