Repository navigation
npm up -g breaks npm (for iojs) #1263
Description
Bundled npm gets iojs sources from iojs site, but when I npm up -g, the new npm goes to nodejs site. This breaks the build system.
Now in more details.
The commit https://github.com/cjihrig/io.js/commit/cdbb640359d07d4243dd63fdeadb42da7b6c439e forces the bundled npm to get the sources from
var tarballUrl = tarPath ? tarPath : distUrl + '/v' + version + '/iojs-v' + version + '.tar.gz'When I npm up -g, I now have the line:
var tarballUrl = tarPath ? tarPath : distUrl + '/v' + version + '/node-v' + version + '.tar.gz'Then I try to install other modules and GYP build fails, because it wants node-v1.6.2.
Activity
kenany commentedon Mar 25, 2015
@iliakan Yeah, I bet
npm up -gis overwriting the patch by downloading un-patchednpmfrom the registry. I don't think that can be prevented. You can at least use the--node-gypflag to configurenpmto use something like pangyp for building:iliakan commentedon Mar 25, 2015
I see there's a work going on, wondering when it's going to be finished. Now using pangyp after npm up as @kenany suggested.
Maybe the issue is worth documenting until fixed.
silverwind commentedon Mar 27, 2015
Isn't this an npm issue?
cc: @othiym23
silverwind commentedon Apr 9, 2015
@iliakan I don't think this issue can be solved by a change in io.js unfortunately. I cursorly checked npm's issue tracker but couldn't find this exact problem. Please open an issue there!
othiym23 commentedon Apr 9, 2015
This happens because the floating patch we apply to npm for io.js releases gets lost when you upgrade npm. Ultimately, this is on @rvagg's plate, because there's a fix to
node-gyp(see nodejs/node-gyp#564 for details) that's blocking on #493 to land and get a fixed release ofnode-gypout. An alternative is to go ahead and upgrade, and use--node-gyp=pangypas a parameter when using npm to install or upgrade packages with native dependencies.othiym23 commentedon Apr 9, 2015
(Also, please don't file issues about this on npm, because without a new release for
node-gyp, there's not a lot we can do about it either.)silverwind commentedon Apr 9, 2015
Thanks for clearing that up, I think I finally understand the issue chain here 😉
iliakan commentedon Apr 9, 2015
(@silverwind But this stays closed?)
silverwind commentedon Apr 9, 2015
As I see it, this issue isn't directly actionable (while #493 is).
silverwind commentedon Apr 9, 2015
On the other hand, seeing that both linked issues got stale, we should also look into alternate ways of fixing this, if
process.releaseis getting too complicated.brendanashworth commentedon Aug 14, 2015
process.releaselanded in #2154, but I'm not sure if this will be an issue going forward with the converged release... thoughts?Fishrock123 commentedon Aug 27, 2015
Please see nodejs/node-gyp#701