Skip to content

please remove node symlink from iojs installer #796

Description

@sintaxi

Is there a good reason the iojs installer creates a node symlink? Its seems quite invasive to me and not in the spirit of being a good open source citizen so I'm hoping there is a good reason for it to be there. If not, please remove it.

Apart from it being inappropriate its also inconvenient as I'm sure many people want to dabble with iojs while maintaining their production NodeJS systems. This makes it more challenging and will create unexpected behaviour for those who do not read the installer process.

banners_and_alerts_and_install_io_js_and_downloads

Activity

  1. Florian-R commented on Feb 11, 2015

    @Florian-R

    #389 #631 #776 and probably a shitload of others.

  2. targos commented on Feb 11, 2015

    @targos
    Member

    If you need Node.js and io.js to coexist on your system, you can use nvm

  3. added
    duplicateIssues and PRs that are duplicates of other issues or PRs.
    on Feb 11, 2015
  4. sintaxi commented on Feb 11, 2015

    @sintaxi
    Author

    Is it really to much to ask for an explanation for this? What purpose does this symlink serve?

    I would like to switch https://github.com/sintaxi/harp to iojs but this is preventing me from doing that as I'm not comfortable forcing the harp community to abandon NodeJS. This behaviour hostile and unprofessional and the lack of explanation leads me to believe this "feature" is self-serving and not operating in good faith. Please don't dismiss this without an explanation as to why iojs feels compelled to override competing binaries on my machine.

  5. tonylukasavage commented on Feb 11, 2015

    @tonylukasavage

    This does seem like a good case for a simple confirmation in the installer as to whether or not you want the symlink

  6. brianloveswords commented on Feb 11, 2015

    @brianloveswords

    @sintaxi I think the explanation is here: #249 (comment) (and there's an even longer discussion at #631)

  7. targos commented on Feb 11, 2015

    @targos
    Member

    It is like MariaDB vs MySQL : io.js is a replacement for Node. Too many modules/scripts rely on the node executable.

  8. vkurchatkin commented on Feb 11, 2015

    @vkurchatkin
    Contributor

    This was closed primarily because it is a duplicate. You can find extensive explanation in linked issues

  9. vkurchatkin commented on Feb 11, 2015

    @vkurchatkin
    Contributor

    @sintaxi your harp project relies on this as well as many other packages: https://github.com/sintaxi/harp/blob/master/bin/harp#L1

  10. sintaxi commented on Feb 11, 2015

    @sintaxi
    Author

    Harp is asking for NodeJS because that is what it depends on.

    I would like Harp to depend on iojs instead but I'm not going to force the entire Harp community to abandon NodeJS just because Harp wants to use iojs. I can't in good conscience force this decision on them because its not my place to make that decision for them.

  11. Fishrock123 commented on Feb 11, 2015

    @Fishrock123
    Contributor

    @sintaxi io.js symlinks to node so that it is usable as node, and so that your files with #!/usr/bin/env node will not break.

  12. sintaxi commented on Feb 11, 2015

    @sintaxi
    Author

    @vkurchatkin btw - thanks for the explanation. If you prefer to close this ticket I can move discussion to issue #249

  13. sintaxi commented on Feb 11, 2015

    @sintaxi
    Author

    @Fishrock123 I understand the explanation it just isn't based on facts. If the user has NodeJS installed which is what the script is asking for, it will run just fine. In reality the scripts are much more likely to break if some systems run node as nodejs and others run iojs.

  14. indexzero commented on Feb 11, 2015

    @indexzero

    @Fishrock123 what about a bin shim that would run iojs or node depending on external config? Or maybe at least making this an option in the installer?

  15. 33 remaining items

  16. notpushkin commented on Mar 5, 2015

    @notpushkin

    @targos Thanks for the nvm advice!

  17. guiprav commented on Apr 27, 2015

    @guiprav

    Sorry to ressurect this thread, but can't io.js replace the node executable by an executable that will first check if another version of Node is installed and use that, otherwise it uses iojs?

    That way, programs that strictly depend on iojs can use #!/usr/bin/env iojs, and iojs will try to run Node scripts if NodeJS itself is not present.

    I honestly do not understand why no one is discussing this possibility. It seems like the most obvious one to me. I'm not saying it's perfect; it just seems the best to me. A version manager would be great, if only version managers didn't tend to suck so bad. They're my main grudge against Python and Ruby. I really didn't want to see Node going that way.

    @indexzero, what do you think of that?

    Edit:

    Are packages compiled for iojs via npm installed on a special iojs directory or are they stored on the same directory Node uses? If the latter, than more would need to be done to get both to work side-by-side.

  18. rvagg commented on Apr 28, 2015

    @rvagg
    Member

    replace the node executable by an executable that will first check if another version of Node is installed and use that

    So, if we overwrite an existing node installation with an executable, what is there to detect, since the previous one has been removed?

  19. schme16 commented on Apr 28, 2015

    @schme16

    @rvagg: I think what @n2liquid means, is to replace the node binary inside the iojs directory with a binary that first checks if there is an existing node installation, and only links to the iojs binary when there isn't an existing node installation (feel free to correct me @n2liquid).

    (@rvagg: totally off topic, but I loved the the latest NodeUp - Never enough of us ANZAC's around, haha)

  20. rvagg commented on Apr 28, 2015

    @rvagg
    Member

    "iojs directory" only makes sense on Windows, everywhere else it's a shared PATH space like /usr/bin or /usr/local/bin where you have only one of a thing with a particular name.

  21. schme16 commented on Apr 28, 2015

    @schme16

    @rvagg: ahh, that's true, my Windows past is showing; feel free to ignore me.

  22. guiprav commented on Apr 28, 2015

    @guiprav

    @rvagg: So I trust it you've considered deeply the possibility of replacing the node executable with a delegator script and to the best of your knowledge it's not viable, correct?

    This is tough. I know it is. But it's insane to think there isn't a simple solution to it. GNU has come a long way, and there's still no easy way to handle this? This doesn't look like an uncommon scenario: Two or more packages offer the same executable. User can select which one he wants at anytime and if the one in use is removed, it falls back to another one, until there is no more options left; then the executable is gone.

    I think I've seen some package managers offering such a feature (Portage?), but not all.

  23. rvagg commented on Apr 28, 2015

    @rvagg
    Member

    Debian-based systems do it with alternatives but that needs to happen at a package-level, we're considering this over at https://github.com/nodesource/distributions but we have enough on our plate right now that it's not a high priority.

    OS X installers are pretty rudimentary and I really don't know what the state-of-the-art is there (or if there is such a thing - they don't even do "uninstallers" on OS X).

    Windows is ironically best placed to do this easily given the mechanism you're proposing.

    However, what you've suggested involves a lot of magic on the user's behalf, you're making an assumption about what they are wanting to actually invoke and you don't have enough information to even make an informed assumption! The most straight-forward way to make an assumption about what the user is wanting to invoke is to just use the version they last installed, which is the current situation now across all of our installers. Running both io.js and Node.js on the same computer is something that only concerns some developers, most devs and I'd suggest almost all production deploys will only be using one version of one project. Given that version managers like nave, n, nvm, nvm.sh have adapted to the new reality of letting you install multiple versions and do it quite well, this issue is a very low priority for the project.

    If you want to run Node.js, install that, if you want to run io.js, install that, if you want to run both for some reason, use a version manager, they are perfect for developers and give you an easy way to always grab the latest version as a bonus.

  24. schme16 commented on May 1, 2015

    @schme16

    @rvagg 👍

  25. afshinm commented on May 14, 2015

    @afshinm

    +1

  26. Fishrock123 commented on May 14, 2015

    @Fishrock123
    Contributor

    Now that we've agreed to merge into the Node Foundation there's not really a point. Maybe if someone can put in the work for a patch to make it optional.

  27. rambo-panda commented on May 18, 2015

    @rambo-panda

    https://www.binarysludge.com/2015/01/14/how-to-uninstall-io-js-or-io-js-and-node-js-together/

    sudo rm /usr/local/bin/node && ln -s /usr/local/Cellar/node/0.10.32/bin/node /usr/local/bin/node
    node --version 
    iojs --version
  28. anthonybrown commented on Jun 30, 2015

    @anthonybrown

    👍 rambo-panda
    Just came here from the binarysludge article, now I ask, why the symlink to node?

  29. Fishrock123 commented on Jun 30, 2015

    @Fishrock123
    Contributor

    Why: in short, so that node executable files work properly. (See above for more context.)

    No such symlinks will exist in the converged node because it will only be node.

  30. locked and limited conversation to collaborators on Jun 30, 2015
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

    duplicateIssues and PRs that are duplicates of other issues or PRs.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions