Raspbian Bullseye 64 Bit install error about leveldown HOT 9 CLOSED

Funnily enough, they moved node-gyp 7.x to a peer dependency in github, but [email protected] (the latest npm version) still has an explicit dependency on node-gyp 3.x which threw me off.

from leveldown.

It's not a problem with node-gyp. This is related to your version of python. It's trying to use python 3.

from leveldown.

@ralphtheninja I agree that its not a problem with node-gyp. Its more so that because another dependency has a specific version of node-gyp installed, npm install uses that version instead of a later version of node-gyp. Since level or any of its sub dependencies don't have a specific version of node-gyp, the build process will use whatever npm resolves with.

By default, I believe Raspbian Bullseye only comes with python3.

from leveldown.

Manually installing the latest version of node-gyp (8.x.x) in my package allows the install to complete.

That is the right solution here, as it prevents sqlite's version from being hoisted (i.e. the old node-gyp will be at node_modules/sqlite3/node_modules/node-gyp).

We can't really say leveldown should have node-gyp in its dependencies just because sqlite has it; it's more common to depend on npm's bundled node-gyp (which is tied to the Node.js version that npm itself was bundled with).

from leveldown.

The annoying part here is that even if I have a global version of node-gyp installed, npm will still use the package defined version of node-gyp when trying to build.

PS. This is not an npm behavior: npm uses its own bundled node-gyp (which can also be annoying). Preferring a locally-installed node-gyp is a node-gyp-build behavior. For addon authors that dó need a custom version of node-gyp.

The resulting situation is... unfortunate.

from leveldown.

@ralphtheninja I agree that its not a problem with node-gyp. Its more so that because another dependency has a specific version of node-gyp installed, npm install uses that version instead of a later version of node-gyp. Since level or any of its sub dependencies don't have a specific version of node-gyp, the build process will use whatever npm resolves with.

By default, I believe Raspbian Bullseye only comes with python3.

Ah! Thanks for clarifying this.

from leveldown.

The annoying part here is that even if I have a global version of node-gyp installed, npm will still use the package defined version of node-gyp when trying to build.

PS. This is not an npm behavior: npm uses its own bundled node-gyp (which can also be annoying). Preferring a locally-installed node-gyp is a node-gyp-build behavior. For addon authors that dó need a custom version of node-gyp.

The resulting situation is... unfortunate.

Ok this make sense. Since node-gyp-build is preferring a local dependency, is this something that would make sense specifying then based on the tools level is using? i.e Since using node-gyp-build it makes sense to specific version of node-gyp, otherwise you would normally just rely on the system version?

Another option would be peer dependencies, but Idk how well that would fit. I don't see many packages opt in favor of them.

Ultimately, I'm fine with having to specify the version of node-gyp in the top package file, but I could see other people running into the same problem with other packages, not just sqlite3.

from leveldown.

Many (likely most) people don't need node-gyp at all, because we include prebuilt binaries. Otherwise I'd be fine with having an explicit dependency on node-gyp.

Another option would be peer dependencies, but Idk how well that would fit.

Yeah, doesn't fit. Because who's the peer that brings node-gyp?

Latest sqlite3 depends on node-gyp@7 btw, so upgrading sqlite3 could be another option.

from leveldown.

Closing because for the time being, at least until more folks run into issues with this delicate balance of dependencies, I want to keep things as-is.

from leveldown.