The binary and long term compatibility with node

[jondavidjohn]

There has been a bit of discussion in #28 about what to name the binary. This probably deserves it's own discussion.

The proposed approach

Is the plan to have the installer install an iojs binary and an alias to node?

presents some additional questions:

• how do node / iojs live side by side?
• is it a goal of iojs to be long-term compatible with node?

[mikeal]

is it a goal of iojs to be long-term compatible with node?

Initial releases, 100%, but being that we have no control over where Joyent will take their fork in the future we can't really commit to staying compatible with whatever they decide to do. If there is a divergence we might choose to deprecate the "node" binary which is one reason I think it's important to install the iojs binary as well.

[kenperkins]

I think that absent a node alias or binary, iojs would be DOA.

+1 on being able to defer the decision on deprecating node long term, also +1 on proactive thinking with doing an iojs binary now

[ghostbar]

FFmpeg was forked into LibAV, LibAV used the same FFmpeg binary names without any issue, at the end LibAV diverged a lot from FFmpeg removing bunchs of functionalities and then they stopped using ffmpeg binary name but people already migrated their scripts to libav if they actually used libav.

I think that was the right approach on the long-term and short-term.

(The example is based on the fact that FFmpeg may be even bigger than node and it worked).

Other thing, I remember the name node is already used by other binary from the ham-community (reason why node is Debian-based systems is usually called nodejs instead of plain node. I think that won't happen with iojs).

[mikeal]

@ghostbar thanks for that story, it's incredibly relevant and puts to ease some of the concerns we've had.

[kenperkins]

mariadb is another example of a fork that uses the same binary and directory naming conventions. Here's a web-page from their site:

https://mariadb.com/kb/en/mariadb/documentation/getting-started/binary-packages/installing-mariadb-binary-tarballs/

The've also diverged, but are still mysql.

[klaemo]

Another thing that'll come up is the engines field in package.json. There needs to be a way to differentiate between node and iojs.
Let's say, I build a module or an app that depends on some of the newer v8 features, I'd need a way to communicate that to the modules's consumers or the PaaS (in case of an app) or whatever.

[yuchi]

@klaemo’s point is important. And my 2¢: it should be io not iojs in the engines, even if it breaks vertical align with node.

[jondavidjohn]

While providing a node alias and having an expectation of compatibility, is there some plan to track explicit compatibility? A map of say iojs 1.x => nodejs 0.12.x?

see #46

[ghostbar]

IMO node was already too generic and as a consequence too bad, io would make it worst. It's not like this project is the only thing that will make I/O in a system, so it should be iojs.

[kenperkins]

fwiw, I just went through the mariadb-server install when installing over mysql-server on ubuntu using apt-get and the install succeeded without any warnings what-so-ever. It basically over-wrote my mysql install.

[jondavidjohn]

Good idea @kenperkins, interesting experiment.

[ghostbar]

@kenperkins that's because it uses the alternatives from Debian-based distros, where you can have it called the same way and link to mysql based on the alternatives proposed.

It's the same way with generic names like editor which in my case links to vim but in the default system links to nano.

[othiym23]

There are already at least two programming languages named io, and any two-character name should be considered a no-go. I would be interested in hearing arguments in favor of "io" over "iojs" for the binary name, but I feel like I need convincing.

[talon]

I don't think io should even be a consideration. Way too generic.

[kenperkins]

+1 for iojs in lieu of just io

[greduan]

👍 For iojs.

[juliangruber]

people that really care will alias io='iojs' anyways

[greduan]

io has a higher probability of conflicting with other commands though

[snostorm]

Noting the discussion here (re: the project's default command line name) may relate to the outcome of #118

[bnoordhuis]

Per today's TC meeting, the plan is to rename to binary to iojs and ln -s iojs node on install if a node binary doesn't already exist. How to make the symlink work on Windows is up for discussion, see #140.

[kenperkins]

@bnoordhuis so that means that if node is already present, we won't do anything (wrt to the symlink, or removing node)?

I'm not sure I like the idea that depending on the state of the system, invoking node may or may not result in the iojs binary being executed.

I wonder if we'd be better off being more explicit in our behavior; a couple of options:

1. Always fail to install if node is already present (i.e. conflict)
2. Stomp on the node install and replace it with iojs (like mariadb)

Thoughts?

[kkoopa]

NAN requires executing 'node' to find the location of the header. Windows compatibility is the main source of problems when it comes to using multiple alternative names. nodejs/nan#70

[bnoordhuis]

@kenperkins After thinking about it some more, I fear that stomping on an existing install is probably the only workable approach. I didn't realize how much stuff the installer installs into $prefix/include and $prefix/lib and I don't think it's possible to detect whether that's from a joyent/node or iojs install.

[kenperkins]

Considering #249 and #42 where does this issue sit? Seems like in #249 a decision has been made, so I think that should be reflected here and maybe close this one?

[DomT4]

Having iojs alias back to node with both binaries being available to call in the $PATH, It's going to make packaging iojs alongside node hell. Completely understand and appreciate why it needs to be done, but I wiggle uncomfortably on the potential for iojs and node to just play the "let's override each other's links" game if they're installed side-by-side.