n-riesco / ijavascript

IJavascript is a javascript kernel for the Jupyter notebook
Other
2.18k stars 187 forks source link

"Error: Could not locate the bindings file." #76

Closed gnestor closed 7 years ago

gnestor commented 8 years ago

I ran into this issue and solved by uninstalling and reinstalling ijavascript globally. It probably was related to the initial installation being installed with Node < 6 and an update being installed with Node 6.

/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:91
  throw err
  ^

Error: Could not locate the bindings file. Tried:
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/Debug/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/Release/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/out/Debug/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/Debug/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/out/Release/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/Release/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/default/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/compiled/5.12.0/darwin/x64/zmq.node
    at bindings (/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:88:9)
    at Object.<anonymous> (/usr/local/lib/node_modules/ijavascript/node_modules/zmq/lib/index.js:6:30)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/usr/local/lib/node_modules/ijavascript/node_modules/zmq/index.js:2:18)
    at Module._compile (module.js:413:34)
rgbkrk commented 8 years ago

Yeah I run into this with every upgrade too. We need to find some way to link to one of these issues about it/documentation around it.

n-riesco commented 8 years ago

@rgbkrk Perhaps we should open an issue at the npm repository. Ideally, when node changes, we'd like npm to recompile all the native modules.

gnestor commented 8 years ago

@n-riesco What if ijavascript added an npm postinstall script that runs npm rebuild?

n-riesco commented 8 years ago

@rgbkrk @gnestor Could you post some instructions to reproduce this issue? And perhaps also the output of npm --versions?

n-riesco commented 8 years ago

Would you be able to check whether adding zmq to the dependencies in package.json works around this issue?

gnestor commented 8 years ago

I use the n package to switch between versions of Node. To reproduce:

  1. Install ijavascript using Node ^5
  2. Switch to Node ^6
  3. Run jupyter notebook using jupyter notebook or ijs
  4. Create a new notebook with "Javascript (Node.js)" kernel
  5. The kernel dies and the output in the terminal is:
[I 08:37:04.501 NotebookApp] Kernel started: 655e00a7-0e94-499b-8b9e-79d28f380309
/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:83
        throw e
        ^

Error: Module version mismatch. Expected 48, got 47.
    at Error (native)
    at Object.Module._extensions..node (module.js:568:18)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at bindings (/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:76:44)
    at Object.<anonymous> (/usr/local/lib/node_modules/ijavascript/node_modules/zmq/lib/index.js:6:30)
    at Module._compile (module.js:541:32)
[I 08:37:07.471 NotebookApp] KernelRestarter: restarting kernel (1/5)
/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:83
        throw e
        ^

To fix, either:

Again, adding an npm postinstall script that runs npm rebuild will fix the issue I experienced which was produced by running npm install -g ijavascript in a different version of Node (because npm install doesn't automatically rebuild native modules). However, if a user switches versions of Node and doesn't run npm install -g ijavascript, then they will encounter this error and there is really nothing we can do about it (and there's really nothing npm can do about it either). To address this, perhaps something along these lines could be added to the README:

Known issues

Lastly, zmq is the culprit here because it's zmq's native modules that need to be rebuilt, so removing the dependency on zmq's native modules would resolve this issue and I believe this is something that @rgbkrk has been working on...

n-riesco commented 8 years ago

@gnestor The error message you get now is different. The original error message in this issue was Error: Could not locate the bindings file..

@rgbkrk What error message do you get in your case?

An Error: Module version mismatch. Expected 48, got 47. is expected whenever process.versions.modules changes (e.g. when Node is upgraded from 5 to 6). In this case, users should be advised to run npm rebuild (or apm rebuild if an electron app?), rather than running npm install.

gnestor commented 8 years ago

@n-riesco You're right! I had an older version of ijavascript installed (probably 1 year old) and I ran npm install -g ijavascript to update it (which didn't rebuild). I encountered this error, uninstalled, and reinstalled (which did rebuild) and the error went away.

One issue with instructing users to run npm rebuild is that you can't run it globally (e.g. npm rebuild -g ijavascript), so the user would need to run it within the ijavascript directory, which if installed globally would be somewhere like /usr/local/lib/node_modules/ijavascript.

rgbkrk commented 8 years ago

This makes me wonder if having an ijs --upgrade option would allow us to do it intelligently. That or we rebuild on start up. Both of these may be silly ideas though.

I'm an nvm user, so the messages are quite similar to n. Sometimes the entire directory for an old version gets nuked by me, and it's the version that was mapped in the kernel spec. I'm used to dealing with native module and upgrades so I just install all over again (unlike a global node install).

n-riesco commented 8 years ago

I've opened an issue in the jmp repository.

n-riesco commented 7 years ago

Moved back from https://github.com/n-riesco/jmp/issues/15

n-riesco commented 7 years ago

After the experience gained with https://github.com/n-riesco/jp-babel/commit/2c7227c7a6fdda3cffbcd78e132efc7df43eab84 I'm convinced this rebuild issue shouldn't be handled by a package itself, because the package would have to know about the environment were it has been installed (is it plain npm? is it electron? ...).

For this reason, I'm going to close this issue.