Repository navigation
please remove node symlink from iojs installer #796
Description
Activity
If you need Node.js and io.js to coexist on your system, you can use nvm
- addedduplicateIssues and PRs that are duplicates of other issues or PRs.Issues and PRs that are duplicates of other issues or PRs.
on Feb 11, 2015 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.
This does seem like a good case for a simple confirmation in the installer as to whether or not you want the symlink
@sintaxi I think the explanation is here: #249 (comment) (and there's an even longer discussion at #631)
It is like MariaDB vs MySQL : io.js is a replacement for Node. Too many modules/scripts rely on the
nodeexecutable.This was closed primarily because it is a duplicate. You can find extensive explanation in linked issues
@sintaxi your harp project relies on this as well as many other packages: https://github.com/sintaxi/harp/blob/master/bin/harp#L1
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.
@sintaxi io.js symlinks to node so that it is usable as node, and so that your files with
#!/usr/bin/env nodewill not break.@vkurchatkin btw - thanks for the explanation. If you prefer to close this ticket I can move discussion to issue #249
@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
nodeas nodejs and others run iojs.@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?
33 remaining items
@targos Thanks for the
nvmadvice!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.
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?
@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)
"iojs directory" only makes sense on Windows, everywhere else it's a shared
PATHspace like/usr/binor/usr/local/binwhere you have only one of a thing with a particular name.@rvagg: ahh, that's true, my Windows past is showing; feel free to ignore me.
@rvagg: So I trust it you've considered deeply the possibility of replacing the
nodeexecutable 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.
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.
@rvagg 👍
+1
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.
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👍 rambo-panda
Just came here from the binarysludge article, now I ask, why the symlink to node?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.- locked and limited conversation to collaborators
on Jun 30, 2015
Is there a good reason the iojs installer creates a
nodesymlink? 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
iojswhile maintaining their production NodeJS systems. This makes it more challenging and will create unexpected behaviour for those who do not read the installer process.