Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

npm up -g breaks npm (for iojs) #1263

Closed
iliakan opened this issue Mar 25, 2015 · 12 comments
Closed

npm up -g breaks npm (for iojs) #1263

iliakan opened this issue Mar 25, 2015 · 12 comments
Labels
npm Issues and PRs related to the npm client dependency or the npm registry.

Comments

@iliakan
Copy link

iliakan commented Mar 25, 2015

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
Copy link
Contributor

kenany commented Mar 25, 2015

@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
Copy link
Author

iliakan commented 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
Copy link
Contributor

Isn't this an npm issue?

cc: @othiym23

@mscdex mscdex added the npm Issues and PRs related to the npm client dependency or the npm registry. label Apr 3, 2015
@silverwind
Copy link
Contributor

@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
Copy link
Contributor

othiym23 commented 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 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
Copy link
Contributor

othiym23 commented 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
Copy link
Contributor

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

@iliakan
Copy link
Author

iliakan commented Apr 9, 2015

(@silverwind But this stays closed?)

@silverwind
Copy link
Contributor

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

@silverwind
Copy link
Contributor

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.

@silverwind silverwind reopened this Apr 9, 2015
@brendanashworth
Copy link
Contributor

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

@Fishrock123
Copy link
Contributor

Please see nodejs/node-gyp#701

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
npm Issues and PRs related to the npm client dependency or the npm registry.
Projects
None yet
Development

No branches or pull requests

7 participants