Node.js and io.js should not break each other (no, they shouldn't)

[caitp]

Based on twitter conversation, the main pain point seems to be io.js symlinking "node" to "iojs" during installation, thus breaking local development environments for Node.js applications/services, which is a problem for people who need to keep node.js working properly, but still want to play with iojs.

SO, some proposed solutions include my idea of a "default JS shell application" which makes sense for win32 and macs, but is harder to do for various linux distributions. This doesn't help with experimentation-on-the-side that much, and is complicated. Another variation on this theme is defining a standard environment variable which would point to the "js shell binary" --- so this could be $NODEJS or $JSSHELL or whatever.

It should be possible to deliver fixit installers which work for Node.js as well as io.js to set up the default shell variable for people, and maybe someone could land a way to set up a default shell variable into Node installers, as well as into io.js installers, to make this easy for people without an extra, unrelated setup tool.

The pros: Allows experimenting with io.js without breaking your production Node stuff (and vice versa, I guess). Also offers a nice way around the debian nodejs binary issue without symlinking or aliasing.

The cons: could take community some time to warm to the idea of having to use a shell variable to figure out which binary to use.

Node contributors could possibly help come to a compromise that allows both to operate side by side, without requiring vagrant or docker or vmware or nvm or any other massive pain in the arse

[Qard]

I don't see how nvm is a pain. If you want multiple versions of a thing trying to do the same thing, you probably want a version manager to handle that.

Anyway, the issue of #!/usr/bin/env node being present in basically every CLI tool in npm to identify what to run with eliminates any other options.

[caitp]

no it doesn't, that's what you call an "excuse". NVM is pretty terrible, it's a pain in the ass, and it still limits simultaneous installs workability.

What we need to do is stop making nonsense excuses, and start actually solving the problem, for realsies. An environment variable is a good start, so lets make that happen.

[rvagg]

No, it's not really a good start, there is a current universal use of the "node" executable name, in hashbangs and even in simple scripting, requiring a universal change to executable name to just make stuff work is not an acceptable solution and certainly doesn't make io.js a viable replacement for Node.

There is an expectation problem here, those of us who are putting a lot of effort into this project and not joyent/node are seeing this as the replacement for Node, this is the 1.0.0 that joyent/node will never get, this is the executable that we will all be using to run Node programs. Obviously, people who are downloading the installers to "try it out" don't share that view, or simply don't have an opinion about such things and just want to take it for a spin and are getting frustrated at it not behaving like something which you just take for a spin.

The Windows installer has an uninstall function which is trivial to run. It also now has an advanced option to let you stop it making a symlink but that is certainly not advised because without a node executable it's mostly only useful for running a REPL and trivial programs.

Linux users are used to make install and make uninstall or tar zxvf and then removing what went there before. We'll also have .deb and .rpm packages also but they will also give you a node executable and will be marked as being in conflict with "nodejs" packages because of this, but you'll have an easy mechanism to switch via your distribution's package manager.

The deficiency I see here is OSX, I'm not aware of a simple uninstall mechanism for .pkgs and I'm certainly no expert on this and my contributions to this so far have been to mostly reuse what already exists from from joyent/node along with some textual additions to the installer to note the modified behaviour.

If you want the OSX installer to behave differently then please figure out how to make this different and submit a pull request for it to https://github.com/iojs/io.js/tree/v1.x/tools/osx-pkg.pmdoc or suggest a replacement to PackageMaker (I certainly wouldn't object to that because it's ancient and unsupported software at this stage). I don't have any other suggestions other than to put an obtrusive popup on the website to highlight "unstable". When we're at "stable", I don't see a reason for people to be running both io.js and Node.js on the same system without a tool like nvm.sh, just like people shouldn't have a reason to run 0.8 and 0.10 on the same system.

[caitp]

there is a current universal use of the "node" executable name, in hashbangs and even in simple scripting,

1. this name is not universal (debian)
2. so what? get people using an environment variable in their shebang line/etc, problem solves itself (it at least doesn't become any more broken)
3. this is an excuse --- it's not a real constraint, it's not really a blocker, it's just another thing to encourage the community to fix in their code

The deficiency I see here is OSX, I'm not aware of a simple uninstall mechanism

Uninstallers aren't really a solution, since the problem is side-by-side installation. Node and io.js can't be a one-or-the-other deal, as they are separate packages

[netpoetica]

As a side note to this, I do think there could at the very least be a "recommended method for managing iojs and nodejs instances." I have to imagine that core contributors to iojs have some good solutions they are using during development that would be great to share in a clear location (repo homepage, iojs FAQ).

For example, the idea of using nvm I think can be a valid for most use cases (dabbling, experimenting), but I was not aware that nvm had even started supporting iojs.

I'm on Mac and I usually go back and forth between iojs and node by running make install in the respective source folders as needed (as long as you've already built the source, this is very fast).

I definitely can see @rvagg point here where the core contributors are / have to be treating iojs as a primary without a secondary - respectable and understandable. I would be curious though, in an effort to make this thread productive, what other folks are currently doing (especially heavily active users) to mitigate this issue?

[jbergstroem]

@caitp I feel like you're still barking up the tree here. Just because (as @rvagg pointed out) a lot of people want to try out io.js doesn't mean that io.js has a responsibility to solve interoperability with nodejs. It's a suggested replacement. There's already tools that handles multiple installs of nodejs, and most – if not all – are gunning to solve this problem for you.

[rlidwka]

1. this name is not universal (debian)

Yes it is.

Well... technically nodejs package doesn't have node executable, but this arrangement causes so many issues that debian folks usually either install nodejs-legacy to get that, or just manually symlink /usr/bin/node to /usr/bin/nodejs.

2. so what? get people using an environment variable in their shebang line/etc, problem solves itself (it at least doesn't become any more broken)

That's fine with me. You can ask people to use env variables that point to nodejs or iojs depending on runtime they want to use. And old scripts will still point at node.

But io.js should still install itself as node to provide b/w compatibility.

[caitp]

or just manually symlink /usr/bin/node to /usr/bin/nodejs.

Yes, people find ways to work around the badness that is the current platform. But hey! That badness is still badness! It's still a pain! Whether you can work around it with tools or not is besides the point, and we need to stop making excuses to avoid fixing it.

But io.js should still install itself as node to provide b/w compatibility.

No, it should not! Not if it results in breaking a working node installation, which it very well might. So what if it breaks compat with lots of scripts? That problem can fix itself over time. The breaking other software someone painstakingly installed on their system thing, that won't fix itself.

[rlidwka]

No, it should not! Not if it results in breaking a working node installation, which it very well might.

nodejs-0.11 already breaks a working nodejs-0.10 installation. People who want both to be installed at the same time use nvm.

Same thing here.

[caitp]

People who want both to be installed at the same time use nvm.

People shouldn't have to use tooling to install two separate products simultaneously

Same thing here.

No, this is just another excuse. Listen to yourself making these excuses mate, it's lazy software development. This is not a good sign. It is one thing to manage two or more versions of the same product, it is quite another thing to require tools for two separate products to be installed side by side. Whether one is a fork of the other is irrelevant, they are not the same thing.

Having bad experiences with the project is going to turn people off from it, this is something to fix --- so rather than making nonsense excuses about it, think about ways to actually make the two live together side by side. Io.js is not "a higher version of node", it's not "node 1.0.3", and people are going to want to try it out without killing their node installation.

Here is a list of completely nonsense excuses that have been made, and are continuing to be made, while not having any real value to them:

1. i can't install freebsd on top of linux and expect it to work
2. tools exist to work around the badness that already exists, while not entirely working around the badness
3. error messages should be good enough to help people not break their node.js installs when they're trying to install io.js side by side
4. users are writing broken code and they're always going to write bad code forever, so it's a non-starter because we can't educate developers and get people to fix their bad code
5. this was node.js's fault, so io.js doesn't have to do anything to fix it, only node does, and not even node does.
6. the thing we really need is an uninstaller!

All of these are irrelevant. It doesn't matter whose fault it is, it's bad, it's a problem to fix. Users write broken code, but we don't have to worry about "breaking the web" in server-side-js-land, and these users are more likely to fix their badness. Error messages are great, but they don't really fix the problem. The uninstaller thing, well, yeah you want uninstallers, but uninstalling does not fix the side-by-side issue. Tools do exist. They suck. They work around problems rather than fixing problems. Node.js and io.js are not operating systems, they're not even really "platforms", they're environments for running javascript code. These environments can work side-by-side, and the fact that they don't is because we haven't fixed it yet.

So I don't want to see these excuses, what I want to see is some productive talks on actually solving the problem. There is a problem, it is hurting people who are trying to use iojs next to their work node.js code, and it's something that ought to be addressed.

[Qard]

This is a conversation that has already been had. It was decided that the best, least painful way to deal with every module in npm with an executable using the #!/usr/bin/env node thing was to use the symlink approach. There was much thought that went into that.

If you think you have a better idea that doesn't break the many thousands of executables people expect to be able to install from npm, feel free to elaborate.

[caitp]

ideas have been had --- it's okay if not every package is compatible with io.js right away. plenty are already broken. This is not a "can't break the web" situation, this is a "can fix bad design" situation. Ideas have been proposed above --- more are welcome. Brushing it off as "we love our terrible design" is not a good way go go.

[Qard]

We definitely don't love that we have to rely on this unfortunate hack to function. But you are talking about breaking compatibility with thousands upon thousands of modules in npm which, for many, are completely essential to their workflow. You are trading minor inconvenience on the users part for major inconvenience on the library authors part.

[19h]

This whole discussion is an inflated lack of substance.

If you install node 0.11.14 over 0.10.12, you would expect the former to be replaced. As io.js is intended to be an in-place replacement for node, you would and have to expect by-design that it is replacing the legacy software. On top of that, if you really need concurrent installations, there is no alternative to an iojs version management solution. It is not the scope of io.js to cope with concurrent installations, because that is a user preference.

[domenic]

+1 to everything @rvagg said. Not much else needs to be added. @caitp clearly would prefer a different design, that prioritizes the things she finds important higher, but that is not the direction the project has taken.

[bjouhier]

node.js and io.js side-by-side for dummies:

• install io.js
• reinstall node.js (1 minute)

Then:

$ node -v
v0.10.35
$ iojs -v
v1.0.3

[Qard]

That breaks io.js. All the tools, like npm, would be hooked up to node, not io.js. Hashbangs will open in node rather than io.js, and native modules would be built against node.js, which would be incompatible.

[Fishrock123]

Closing in favor of better documentation on the website.

nodejs/iojs.org#64 (feel free to help!)

[benpptung]

@rvagg, this is just a nodejs user opinion. :)

I think it is impossible that io.js to replace node.js now, but possible in the future( maybe in one year ). So IMHO, it might not be a good start symlinking "node" to "iojs". I see issaac also support io.js, so why not some changes in npm to support both node.js and io.js at the same time, and for example, we can simply use ipm view {package.name} to know if a npm package is also an io.js package. Then, we may see more and more npm packages support both io.js and node.js in the future. ( The npm package author might have to edit package.json to say it also support io.js )

Co-exist might be a good start, although it might be difficult in the initial stage due to few io.js packages. But no co-exist, it means I cannot keep my own node applications development pace, and play io.js at the same time. For example, if I switch to io.js, I am not sure if all my private modules are stable as usual, and I have to run unit-test one by one. Even all of them are passed, I am still worrying if they will behave as usual in production environment. Co-exist will give me chances to get more confidence to io.js and maybe switch to it someday if it proves it is better. Just a suggestion for your reference.