Closed jonathanong closed 9 years ago
:+1:
Depends on how the Joyent Node Advisory Board reacts, and the node-forward TC's response to that, afaik.
I suggested the executable be named iojs
to avoid conflicts.
the executable needs to be named node
, there are far too many existing scripts that use #!/usr/bin/env node
. we aren't going to break the ecosystem, that would be insane :)
I agree - node
isn't a trademarked term and we were all using node.js
in the public domain long before Joyent came along. Trademarking a term in common usage is hard to defend. As for their advisory board, from what I've seen it's just a few big companies looking to stake out cloud-hosting fiefdoms, not based on concern for what developers need.
the executable needs to be named node
Having executable name "node" and project name "io.js" isn't great, because when somebody will search for node, they'll find node.js, not io.js. Just something to think of.
Maybe ask people to use #!/usr/bin/env js
instead? Where "js" is a symlink to whatever js implementation installed on the system (debian-based distros use this thing already). Just a thought.
I can't speak on behalf of the Advisory Board, but if the goal is to ship something that users can use, trying to ship node
is bound to add latency. Shipping something differently named allows forward technical progress to be made. Resolving issues with scripts is straightforward. We already do this on most Debian distributions linking nodejs
to node
.
@rlidwka nice. Can you confirm the namespace is available in common distros?
@dshaw what exactly is going to add latency?
@rlidwka FYI, spidermonkey ships a js
binary, and has been for a long time :)
@mikeal Trademark issues aside, there's already a binary being distributed called node
. In fact, there are two. If the binary is called something else, then it can just ship. If the binary "has to be node
, then there a considerable amount of effort required to get that binary into distribution channels.
I agree with @dshaw on the naming. It also makes it a clean break; avoids confusion. Further, speaking as a the author of a very popular global CLI module, forever
, I will gladly update the bin
script to find node
or iojs
.
@dshaw there is no trademark issue with producing a node
binary. To my knowledge nobody has ever claimed there was. The existing threats have been related to the project name "Node Forward" but claiming the trademark extends to the term "node" or the node
binary would be pure lunacy and, to my knowledge, that claim has never been made.
As to the binary name "already existing" I have two problem with this.
The first is that "shipping something" is most easily accomplished in the short term by not producing binaries and focusing on source releases, moving on to binary releases for various platforms once a release cadence is established.
The second issue I have with this is that we actually are producing releases of node
that implement an API people understand as node
. If you compare this with the various competing Java implementations it would make sense to produce the same binary. For instance, Apache Harmony installs a java
binary, as does every other JVM implementation http://harmony.apache.org/quickhelp_users.html . To bring us back around to the trademark issues, Oracle owns a trademark on exactly the phrase "java" in this exact context and is aggressive about enforcing it, yet it is well established that this just doesn't extend to the binary name, even after Oracle won their appeal copyrighting the Java API this is holding true, so...
@indexzero "avoids confusion" ??? nothing is more confusing than changing the name of the thing you run :)
@dshaw also, note that the name of the binary and the "project name" for installation on various operating systems is not the same. It's possible that people would apt-get install iojs
which then would install a node
binary.
@mikeal I disagree with your position. If a fork begins, it is (by definition) not node. It is certainly "node-like", but will likely diverge in important technical ways. Now lets consider the fact that:
"On average, no one knows anything"
Shipping a binary with the same name as what is was forked from will definitely cause confusion to people who don't understand why X doesn't work with "node" on their system. Where X is a feature implemented in iojs/node
and not joyent/node
or vice-versa.
@indexzero again, this is a well established pattern across the differing JVM implementations.
@mikeal Sorry, "trademark issues aside" was intended to mean that I was not taking in to consideration anything about naming that related to anything legal.
Is it iojs or io.js? If there is to be a new name, it would be great if it could be one new name. I still don't know whether joyent/node is node, nodejs, or node.js and it has always bothered me.
Having iojs (or io.js, whatever the project's name is) as a binary that is aliased as node seems like an appropriate thing for downstream packagers to do, and seems completely separate from whether the binary produced by make
is iojs or node.
After a short conversation with @indexzero it became clear that we were talking about two totally different things when we say "shipping a node" and we're actually in agreement about what should be done.
apt-get install iojs
iojs
binarynode
to iojs
binaryAnybody disagree with that strategy?
@mikeal yes, exactly. If a fork is to occur, it is not "shipping node", it is "preserving backwards compatibility with the node ecosystem via an alias". Something that could easily be turned off via a flag if so desired by the person installing it.
As long as we understand that this will also likely involve marking an iojs
package (rpm and deb) as "conflicting" with nodejs
so that the user is forced to choose one or the other.
@rvagg +1
@rvagg +1 although it technically doesn't conflict with the mainline nodejs
packages since they only install a nodejs
binary right? Just the superior, more maintained versions of them that you're responsible for?
sort of .. the ones that come out of debian now (last I checked) do nodejs
but they also have a "nodejs-legacy" package that does the symlink and contains the conflict and users are encouraged to do both to make it work properly.
regardless though, shipping proper linux packages is going to mean we have to do this because it is a true conflict, I just want to make sure everyone is aware of this.
@rvagg got it. Thanks for the clarification, still definitely a big +1 to informing folks about the conflict.
As long as we understand that this will also likely involve marking an iojs package (rpm and deb) as "conflicting" with nodejs
I think there will be no conflict, if everything is done properly.
nodejs
will install its binary into /usr/bin/nodejs
iojs
will install its binary into /usr/bin/iojs
libmozjs
will install its binary into /usr/bin/js17
/usr/bin/node
to point to iojs
or nodejs
as they prefer/usr/bin/js
to point to any of them as they preferNow if you're a package maintainer, you should use:
/usr/bin/env nodejs
if your stuff is compatible with node.js, but not iojs/usr/bin/env node
if your stuff is compatible with both node.js and iojs/usr/bin/env js
if your stuff is just a general javascript file without any requiresSomething like that. Maybe. I'm not sure, that's just a suggestion.
It's worth to ask debian TC about this, those guys also have ax25-node
conflict to keep in mind.
Debian has a standard way of handling these types of issues with "alternatives". Check out: https://wiki.debian.org/DebianAlternatives
The Debian alternatives system was originally created for Debian but has been picked up by other GNU/Linux software distributions. For example Red Hat now uses a fork of the code to maintain system software such as /usr/sbin/sendmail. On RHEL/Fedora /usr/sbin/sendmail is an alternatives symlink to either the classic Sendmail or to Postfix as alternative implementations of an MTA.
if there are more and more ES runtimes to be born, then @rlidwka's comment is what I was thinking, +1 :checkered_flag:
So in Node.js, we have process.version
, process.arch
, process.platform
, and process.versions
. There will definitely be a way to use something to tell if code is running in Node.js vs io.js, correct? I assume at least there won't be a process.versions.node
entry and instead be like a process.versions.iojs
entry?
Also, anyone know about how npm
will deal with this? Will it start looking in engines.iojs
in the package.json file for the version spec?
Also, anyone know about how npm will deal with this? Will it start looking in
engines.iojs
in thepackage.json
file for the version spec?
Not unless there is a specific reason that npm needs to know which fork it's running on. Pretty much everything I've heard about io.js (and I have my sources ;) leads me to believe that there will be earnest efforts made to prevent that level of divergence, so the npm CLI team's stance is that we will deal with this issue only if it becomes a problem.
Also, I fixated on the npm piece of this (i.e. which features npm needs to run itself), but in general, if it gets to the point where there are serious concerns about platform portability between node
and iojs
, npm can address that, but it's my sincere hope that that doesn't become an issue.
I expect node.js
to update v8 dep very slowly, and it will be a major source of incompatibility between node.js and io.js. I could easily imagine that io.js will support arrow functions soon, but node.js won't.
The one common case when engines
hash is used is to lock node.js version to >= 0.11.4
because of the generator support. Essentially, it depends on v8 version, not node.js version.
So...
@othiym23 , would it make sense for npm to support engines: { v8: "..."}
instead of engines: { node: "..." }
?
Yes, the v8 stuff is one of the immediate ways in which node.js and io.js are diverging and being able to ask for this in package.json
is a concern.
But even then, bugs are just as important. Say my module doesn't work well because of a bug in Node.js (just think 0.10.1 and 0.10.2). Normally I would say >= 0.10.2
and be done with it. Now since io.js seems like it's going to fix some bugs that Node.js is still sitting on, I would not have a way to do this, since I cannot differentiate Node.js and io.js in the package.json
specification...
@rlidwka @dougwilson That is a larger discussion than I'm prepared to get into on this issue, but I think what I said above remains true: if and when this becomes an issue, npm will decide upon a strategy for handling this.
Hi all. Sorry I am so late to the party on this one, day job has been keeping me very busy recently.
IMNSHO the correct way to deal with this, as expressed already by many in this thread, is to install an iojs
binary and symlink it to /usr/bin/node
via the Debian alternatives system. This basically is what I've been doing forever with my nodejs packages for Ubuntu (and now Debian via the NodeSource repo).
The package in Debian that historically has installed a binary to /usr/bin/node
is a program used by HAM radio operators, and as I understand it, they've kindly agreed to rename their binary as "node" is now really understood by folks to be the JS runtime we all know and love. Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=165;filename=ax25-node.debdiff;att=1;bug=681361
It won't truly be phased out for a while, but things are going in that direction, so I don't see a practical problem with putting something at /usr/bin/node
via packages. I would argue that anybody who might run into a conflict is going to be technically savvy enough to sort the situation out for themselves. And, if it's a goal of iojs
in general to have any level of compatibility with nodejs
, then having a node
executable on the $PATH
is simply a requirement.
Adding the needed Conflicts
bits to the packages so that you can't have both nodejs
and iojs
installed at the same time is easy, and probably the right thing to do. But either would be accessed via /usr/bin/node
.
I will of course defer to my colleagues at NodeSource if they think I'm wrong, but I think this is the way to do things that will work the best for the greatest number of people.
they've kindly agreed to rename their binary as "node" is now really understood by folks to be the JS runtime we all know and love.
There was no "kind agreement", only a flamewar in the mailing list and subsequent TC decision, forbidding both packages to use /usr/bin/node
:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#108
Sorry @rlidwka, sarcasm translates really poorly when typed sometimes.
13th of January (or thereabouts)
when's the initial release of io.js? would love even just a beta version so we can start trying
#!/usr/bin/env io
.