Skip to content

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

Description

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

Activity

  1. kenany commented on Mar 25, 2015

    @kenany
    Contributor

    @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
  2. iliakan commented on Mar 25, 2015

    @iliakan
    Author

    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.

  3. silverwind commented on Mar 27, 2015

    @silverwind
    Contributor

    Isn't this an npm issue?

    cc: @othiym23

  4. added
    npmIssues and PRs related to the npm client dependency or the npm registry.
    on Apr 3, 2015
  5. silverwind commented on Apr 9, 2015

    @silverwind
    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!

  6. othiym23 commented on Apr 9, 2015

    @othiym23
    Contributor

    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.

  7. othiym23 commented on Apr 9, 2015

    @othiym23
    Contributor

    (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.)

  8. silverwind commented on Apr 9, 2015

    @silverwind
    Contributor

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

  9. iliakan commented on Apr 9, 2015

    @iliakan
    Author

    (@silverwind But this stays closed?)

  10. silverwind commented on Apr 9, 2015

    @silverwind
    Contributor

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

  11. silverwind commented on Apr 9, 2015

    @silverwind
    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.

  12. brendanashworth commented on Aug 14, 2015

    @brendanashworth
    Contributor

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

  13. Fishrock123 commented on Aug 27, 2015

    @Fishrock123
    Contributor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    npmIssues and PRs related to the npm client dependency or the npm registry.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions