Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The binary and long term compatibility with node #43

Closed
jondavidjohn opened this issue Dec 3, 2014 · 31 comments
Closed

The binary and long term compatibility with node #43

jondavidjohn opened this issue Dec 3, 2014 · 31 comments

Comments

@jondavidjohn
Copy link
Contributor

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
Copy link
Contributor

mikeal commented Dec 3, 2014

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
Copy link
Contributor

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
Copy link
Contributor

ghostbar commented Dec 3, 2014

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
Copy link
Contributor

mikeal commented Dec 3, 2014

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

@kenperkins
Copy link
Contributor

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
Copy link

klaemo commented Dec 3, 2014

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
Copy link

yuchi commented Dec 3, 2014

@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
Copy link
Contributor Author

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
Copy link
Contributor

ghostbar commented Dec 3, 2014

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
Copy link
Contributor

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
Copy link
Contributor Author

Good idea @kenperkins, interesting experiment.

@ghostbar
Copy link
Contributor

ghostbar commented Dec 3, 2014

@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
Copy link
Contributor

othiym23 commented Dec 4, 2014

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
Copy link

talon commented Dec 4, 2014

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

@kenperkins
Copy link
Contributor

+1 for iojs in lieu of just io

@greduan
Copy link

greduan commented Dec 4, 2014

👍 For iojs.

@juliangruber
Copy link
Member

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

@greduan
Copy link

greduan commented Dec 7, 2014

io has a higher probability of conflicting with other commands though

@snostorm
Copy link

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

@bnoordhuis
Copy link
Member

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
Copy link
Contributor

@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
Copy link

kkoopa commented Dec 11, 2014

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
Copy link
Member

@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
Copy link
Contributor

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
Copy link

DomT4 commented Jan 8, 2015

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.

targos added a commit to targos/node that referenced this issue Apr 17, 2021
Original commit message:

    Merged: Squashed multiple commits.

    Merged: [const-tracking] Mark const field as mutable when reconfiguring
    Revision: 7535b91f7cb22274de734d5da7d0324d8653d626

    Merged: [const-tracking] Fix incorrect DCHECK in MapUpdater
    Revision: f95db8916a731e6e5ccc0282616bc907ce06012f

    BUG=chromium:1161847,chromium:1185463,v8:9233
    NOTRY=true
    NOPRESUBMIT=true
    NOTREECHECKS=true
    R=​[email protected]

    (cherry picked from commit 56518020bff4d0e8b82cff843c9f618c90084e42)

    Change-Id: I7f46a701646e1dd67a049b2aa4ac32d05b6885f3
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748079
    Commit-Queue: Georg Neis <[email protected]>
    Reviewed-by: Igor Sheludko <[email protected]>
    Cr-Original-Commit-Position: refs/branch-heads/8.9@{nodejs#43}
    Cr-Original-Branched-From: 16b9bbbd581c25391981aa03180b76aa60463a3e-refs/heads/8.9.255@{#1}
    Cr-Original-Branched-From: d16a2a688498bd1c3e6a49edb25d8c4ca56232dc-refs/heads/master@{#72039}
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794428
    Reviewed-by: Victor-Gabriel Savu <[email protected]>
    Commit-Queue: Artem Sumaneev <[email protected]>
    Cr-Commit-Position: refs/branch-heads/8.6@{nodejs#73}
    Cr-Branched-From: a64aed2333abf49e494d2a5ce24bbd14fff19f60-refs/heads/8.6.395@{#1}
    Cr-Branched-From: a626bc036236c9bf92ac7b87dc40c9e538b087e3-refs/heads/master@{#69472}

Refs: v8/v8@ffde6ee
@Anonimpgk

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests