The binary and long term compatibility with node about node HOT 31 CLOSED

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.

from node.

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

from node.

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

from node.

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

from node.

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.

from node.

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.

from node.

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

from node.

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

from node.

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.

from node.

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.

from node.

Good idea @kenperkins, interesting experiment.

from node.

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

from node.

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.

from node.

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

from node.

+1 for iojs in lieu of just io

from node.

👍 For iojs.

from node.

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

from node.

io has a higher probability of conflicting with other commands though

from node.

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

from node.

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.

from node.

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

from node.

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

from node.

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

from node.

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?

from node.

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.

from node.

Maybe it would be good to semi-officially support/recommend version manages (nvm, n) as part of our website/README. Especially if we can get those projects to support iojs sooner than later. (Or fork our own.)

It could help people maintain both versions and have a clearer sense of which they are on.

from node.

+1 for creating our own version manager.

from node.

I'm pretty sure that's unnecessary, we have version manager authors/maintainers involved here and looking to make them work with io.js: nodejs/build#22

from node.

Don't fork the version manager; as @rvagg mentions there's plenty of interest and desire for the current package managers to stay current with trends in all the forks.

from node.

As long as io.js supports the same things as node.js - namely, curl-able binaries + source, easy-to-consume-from-POSIX version URLs, and path-related environment variables, http://nvm.sh will definitely support io.js.

What the project decides to do with the binary doesn't matter to me wrt nvm, as long as it either stays backwards-compatible, or provides notice for breaking changes so nvm can be updated.

from node.

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?

from node.