You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Issue installing gcloud using command "npm install --save gcloud" #817
F:\Projects\Kiran\Bald-Eagle\mcapi\node_modules\gcloud\node_modules\sse4_crc32>i
f not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\np
else (node rebuild ) ..\node_modules\node-gyp\bin\node-gyp.js" rebuild )
configure error
gyp ERR! stack Error: Can't find Python executable "python", you can set the PYT
HON env variable.
gyp ERR! stack at failNoPython (C:\Program Files\nodejs\node_modules\npm\nod
e_modules\node-gyp\lib\configure.js:114:14)
gyp ERR! stack at C:\Program Files\nodejs\node_modules\npm\node_modules\node
-gyp\lib\configure.js:69:11
gyp ERR! stack at FSReqWrap.oncomplete (evalmachine.:95:15)
gyp ERR! System Windows_NT 6.3.9600
gyp ERR! command "node" "C:\Program Files\nodejs\node_modules\npm\node_modu
les\node-gyp\bin\node-gyp.js" "rebuild"
gyp ERR! cwd F:\Projects\Kiran\Bald-Eagle\mcapi\node_modules\gcloud\node_modules
\sse4_crc32
gyp ERR! node -v v0.12.7
gyp ERR! node-gyp -v v2.0.1
gyp ERR! not ok
npm ERR! Windows_NT 6.3.9600
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs
\node_modules\npm\bin\npm-cli.js" "install" "--save" "gcloud"
npm ERR! node v0.12.7
npm ERR! npm v2.11.3
npm ERR! code ELIFECYCLE
npm ERR! sse4_crc32@3.4.0 install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the sse4_crc32@3.4.0 install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the sse4_crc32 package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-gyp rebuild
npm ERR! You can get their info via:
npm ERR! npm owner ls sse4_crc32
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! F:\Projects\Kiran\Bald-Eagle\mcapi\npm-debug.log
I don't think 4.0 had anything to do with this. The problem here is: "Can't find Python executable "python", you can set the PYTHON env variable." If https://github.com/Voxer/sse4_crc32/issues/39 turns up something else, and we need to update, we'll definitely do that.
@stephenplusplus This is far from the first time this library has caused a problem with installing gcloud. Are there really no alternatives that are more mature for doing CRC checks in Node? Or nothing else we can do to make this less of an issue ?
The thing that's unfortunate about this particular library is that it has native bindings-- that's only unfortunate because all of a sudden, developers get errors they have never seen before and it doesn't make sense why. All they did was install a JavaScript library. These errors will come up any time we use a library with native bindings.
What we can do is look for a software-only equivalent. I've tried in the past without success, but it's probably worth it to try again.
Doesn't CRC32 (regular) give shitty performance but no installation problems?
And then we can document the whole "If you want things to be super fast, just run npm install sse4_crc32 and we'll use that..." and then things will be faster.... ?
Working with the storage API is my first experience with crc32/c, but aren't crc32 and crc32c different algorithms that will give different results? The API gives us crc32c -- if crc32 works the same, then we can use something like this and be done with it. I doubt this type of performance tradeoff is anything the Node users will feel.
We'd need someone more knowledgeable to chime in, however I can say that certain people will definitely notice the difference (the Firebase folks for example definitely will be mad if we regress on performance going from C to JS), so we certainly need the ability to have "the faster way".
Having both would be pretty tricky since the problem happens at the point
of install. Maybe optionalDependencies can help us, I'll have to play with
it a bit to see how that would behave.
Worst case with only supporting the software for those who want hardware
would be that they would have to run the validation themselves. I (or
we) could make a small wrapper in a different module that makes it as easy
as possible.
We'd need someone more knowledgeable to chime in, however I can say that
certain people will definitely notice the difference (the Firebase
folks for example definitely will be mad if we regress on performance going
from C to JS), so we certainly need the ability to have "the faster way".
—
Reply to this email directly or view it on GitHub #817 (comment)
.
Maybe! It's not a pattern I'm familiar with, I'll ask around if there's a
precedent here. If that is our best option, I'd try to modularize that out
and make a seamless API, otherwise our code would be quite gross.
Activity
stephenplusplus commentedon Aug 22, 2015
This is an issue with a dependency we use. Can you report this over on their repo? https://github.com/voxer/sse4_crc32
Thanks, and sorry you ran into this.
stephenplusplus commentedon Aug 22, 2015
I don't think 4.0 had anything to do with this. The problem here is: "Can't find Python executable "python", you can set the PYTHON env variable." If https://github.com/Voxer/sse4_crc32/issues/39 turns up something else, and we need to update, we'll definitely do that.
stephenplusplus commentedon Aug 22, 2015
No problem, we'll just wait to see what they say in https://github.com/Voxer/sse4_crc32/issues/39.
jgeewax commentedon Aug 22, 2015
@stephenplusplus This is far from the first time this library has caused a problem with installing gcloud. Are there really no alternatives that are more mature for doing CRC checks in Node? Or nothing else we can do to make this less of an issue ?
stephenplusplus commentedon Aug 22, 2015
The thing that's unfortunate about this particular library is that it has native bindings-- that's only unfortunate because all of a sudden, developers get errors they have never seen before and it doesn't make sense why. All they did was install a JavaScript library. These errors will come up any time we use a library with native bindings.
What we can do is look for a software-only equivalent. I've tried in the past without success, but it's probably worth it to try again.
jgeewax commentedon Aug 22, 2015
Doesn't CRC32 (regular) give shitty performance but no installation problems?
And then we can document the whole "If you want things to be super fast, just run
npm install sse4_crc32and we'll use that..." and then things will be faster.... ?stephenplusplus commentedon Aug 22, 2015
Working with the storage API is my first experience with crc32/c, but aren't crc32 and crc32c different algorithms that will give different results? The API gives us crc32c -- if crc32 works the same, then we can use something like this and be done with it. I doubt this type of performance tradeoff is anything the Node users will feel.
jgeewax commentedon Aug 22, 2015
We'd need someone more knowledgeable to chime in, however I can say that certain people will definitely notice the difference (the Firebase folks for example definitely will be mad if we regress on performance going from C to JS), so we certainly need the ability to have "the faster way".
stephenplusplus commentedon Aug 22, 2015
Having both would be pretty tricky since the problem happens at the point
of install. Maybe optionalDependencies can help us, I'll have to play with
it a bit to see how that would behave.
Worst case with only supporting the software for those who want hardware
would be that they would have to run the validation themselves. I (or
we) could make a small wrapper in a different module that makes it as easy
as possible.
On Saturday, August 22, 2015, JJ Geewax notifications@github.com wrote:
jgeewax commentedon Aug 22, 2015
Wait... we can't set crc32 (software) as the dependency, and then in code:
?
And then anyone who wants "faster crc checks" can run
npm install sse4_crc32?stephenplusplus commentedon Aug 22, 2015
Maybe! It's not a pattern I'm familiar with, I'll ask around if there's a
precedent here. If that is our best option, I'd try to modularize that out
and make a seamless API, otherwise our code would be quite gross.
On Saturday, August 22, 2015, JJ Geewax notifications@github.com wrote:
1 remaining item
chore(deps): update dependency pb-util to v1 (#817)
chore(deps): update dependency @types/node to v16 (#817)
chore(deps): update dependency @types/node to v16 (#817)
fix: do not pass undefined as option values (#817)
Revert "fix: clarify the gax-nodejs usage in README (#1352)" (#1409) (#…
Revert "fix: clarify the gax-nodejs usage in README (#1352)" (#1409) (#…
Revert "fix: clarify the gax-nodejs usage in README (#1352)" (#1409) (#…
Revert "fix: clarify the gax-nodejs usage in README (#1352)" (#1409) (#…
Revert "fix: clarify the gax-nodejs usage in README (#1352)" (#1409) (#…
Revert "fix: clarify the gax-nodejs usage in README (#1352)" (#1409) (#…
Revert "fix: clarify the gax-nodejs usage in README (#1352)" (#1409) (#…
docs: update createQueryJob documentation (#817)
chore(deps): update dependency yargs to v14 (#817)
test: skip failing test until we can dig into the issue (#817)
chore(deps): update dependency yargs to v14 (googleapis#817)