npm up -g breaks npm (for iojs)

[iliakan]

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.

[kenany]

@iliakan Yeah, I bet npm up -g is overwriting the patch by downloading un-patched npm from the registry. I don't think that can be prevented. You can at least use the --node-gyp flag to configure npm to use something like pangyp for building:

$ npm install --node-gyp=pangyp

[iliakan]

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]

Isn't this an npm issue?

cc: @othiym23

[silverwind]

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

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 of node-gyp out. An alternative is to go ahead and upgrade, and use --node-gyp=pangyp as a parameter when using npm to install or upgrade packages with native dependencies.

[othiym23]

(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]

Thanks for clearing that up, I think I finally understand the issue chain here 😉

[iliakan]

(@silverwind But this stays closed?)

[silverwind]

As I see it, this issue isn't directly actionable (while #493 is).

[silverwind]

On the other hand, seeing that both linked issues got stale, we should also look into alternate ways of fixing this, if process.release is getting too complicated.

[brendanashworth]

process.release landed in #2154, but I'm not sure if this will be an issue going forward with the converged release... thoughts?