add iojs

[aredridel]

No description provided.

[aredridel]

Ugh. Devel-only?

This is the kind of thing that makes me really frustrated with homebrew -- this is the most stable release of iojs; it's not like a bleeding edge release that will supersede another, more stable one.

[mistydemeo]

As long as this is a stable release then that's fine. I'm curious about the "beta" tag, but 1.0.0 is a relatively unambiguous number.

[aredridel]

The API won't change; there may be bugs. This is true of all stable software.

[aredridel]

Added conflict markers and based the formula off of node current

[smockle]

@aredridel You may want to add a message to the conflicts_with, e.g.:

  conflicts_with "node",
  :because => "io.js includes a symlink named node for compatibility."

[aredridel]

Yeah, I'd love to remove the conflicts when it doesn't conflict. Incremental progress is an option!

But if you ask around nobody can define what beta stability means ;-)

[aredridel]

v1.0.1 and note about conflict.

[mistydemeo]

Thanks!

[xu-cheng]

As most of code is identical as the node.rb. I wonder whether all of statements apply to iojs. Such as:

• # Note that x.even are stable releases, x.odd are devel releases
• fails_with :llvm

etc.

[aredridel]

Yes. The handling of icu stuff is very tightly managed to keep the size of the node binary down.

[smockle]

Some details here, from a formula I made for the nightly: smockle-archive/homebrew-iojs@7ebfaf6#commitcomment-9251951.

[aredridel]

Yeah, mostly or entirely. The most recently changed are the most likely to be different of course.

[aredridel]

Ah, awesome. Will do for future new formulae then.

[aredridel]

Is there a way to have a formula depend on one of two formulas? I'd love to make npm depend on node or iojs

[aredridel]

Oh! that explains why I got the error I did. I thought it was just "npm requires node, you have iojs installed" but it's aliased and saying "No, node conflicts with iojs"

[smockle]

Another thing we may want to consider: adding a symlink from /Library/Aliases/io.js to /Library/Formula/iojs.rb. Since some people may try brew install io.js instead of brew install iojs.

[aredridel]

Yeah. Long-term, I'd like to make them not conflict -- the way io.js is handling this is to only install the node symlink if node is not present. Weird, but does what people intend mostly; may need tweaking of the concept for homebrew. npm works the same under each of them, so there's no reason to have two different npm installs, nor need for anything that mucks with your shell like nvm.

[smockle]

@DomT4 Isaac Schlueter, founder of npm, Inc. blogged about npm's commitment to io.js and node:

**What is npm’s position on Node forks?**

npm is the package manager for JavaScript. We support all nodes that are widely used in the
JavaScript community, and do not recommend or prefer any of them over any other.

Node’s community has always been its best feature. With over 100,000 modules today, covering a
breathtaking array of use cases, used every day by millions of developers around the world, it
is clear that the primary value Node provides is a small core enabling userland innovation.

npm remains committed to its mission of reducing friction for all JavaScript developers.

That's not the exhaustive test you describe, but it at least says something about the npm project's intentions.

[smockle]

@DomT4 Would running npm's tests (https://github.com/npm/npm/blob/master/Makefile#L227-228) on supported operating systems with both node and io.js be sufficient?

[bySabi]

How install iojs formula and npm together?
Something like: brew install iojs_url --with-npm ??

[MikeMcQuaid]

@MikeMcQuaid I feel like node (or equivalent) without npm is going to be far less useful for users, and a lot of users would be very confused if they got this without npm. I don't see this as different from having similar code to install pip/setuptools in python2, python3, and pypi.

What if users want to install something that requires node after installing iojs? I think introducing a :node at this stage in development would be overkill and conflicts_with does not play particularly nicely.

A lot of these similar arguments are (and have been) made about qt5 and I agree with the conclusions there too: conflicts_with is a bit of a sledgehammer when dealing with formulae that have many dependants.

Again, I'm open to gradually improving this situation once this gets included. What I'm worried about is it gets included at we get even more issues due to users being confused when things break and we're in a situation where we can't really revoke it.

@jacknagel Any thoughts on any of this?

[DomT4]

On a purely technical point, if Homebrew did include npm as part of iojs despite iojs being kegged, how would that actually work? npm is hard-wired to look for /usr/bin/env node which won't be in the $PATH if it's keg_only, so npm presumably wouldn't work without users having to prepend their $PATH with the opt directory or similar?

If it goes in keg_only I'm not sure npm could be included, given that ingrained /usr/bin/env node element?

[tdsmith]

Could we env-script it?

[mikl]

My two cents as no one in particular, who develops web apps on Node:

While I'd like to try out IO.js, I'm not really interested in anything that would break my standard Node.js development setup. Most devs I know use bower, grunt, gulp, or similar tools that all use node.

So the only way this package will see much use (in my opinion), will be if it can be installed alongside the current Node.js. So, without taking over the node command (so it would only run if you did iojs, and maybe with an aliased npm command to run it via iojs. npm-iojs or similar.

[DomT4]

@tdsmith For npm onto iojs? Probably. But there's also the problem that almost anything npm installs into bin also makes the same #!/usr/bin/env node reference, so then we hit the same problem. We'd have to essentially attempt to script everything.

npm have had a script upstream for a while that would serve this purpose, here, but I'm not sure how comfortable you all feel about that; Theoretically it could be run post-install to adjust for the node non-$PATH binary, and it would work, but I'm not sure how deep that goes. From some initial testing, it works for npm but not for anything else installed via npm, so you'd have a working npm but other modules would still be broken.

Even after using the script and successfully moving the npm onto a different node executable, npm install -g coffeelint@latest still produced a coffeelint executable that had the #!/usr/bin/env node shebang in. @othiym23 probably has a better certain answer on how feasible it would be to go around or play with the shebang though.

[tdsmith]

I think keg-only is a useful starting point and nicer than conflicts_with. I agree with Misty that providing a npm solution seems important.

Do iojs and node proper have different default module search paths or will iojs look in e.g. /usr/local/node_modules?

If we don't need to separate the package libraries for node and iojs immediately, maybe we just recommend that users install node to get npm. CLI scripts will be invoked with node; presumably that's okay for the near term.

If we do want to separate the iojs and node package libraries and CLI scripts and we can't do anything to control the shebangs of the CLI scripts that npm writes for the packages it installs, integrating npm this way will be more challenging. FWIW, I wish that python, python3, and system Python didn't all attempt to write CLI scripts to HOMEBREW_PREFIX/bin. Using a path like /usr/local/share/iojs/bin for iojs CLI scripts would prevent npm-node and npm-iojs CLI scripts from stepping on each other.

[othiym23]

npm's responsibility ends at making sure that the links to package scripts are set up properly during install -- the shebang lines in the individual scripts shipped by packages are the responsibility of the package developers. It would be a nontrivial change to modify npm to rewrite shebang lines by default (except on Windows, which uses the cmd-shim package to do this).

Speaking as the npm CLI team lead, we draw no distinction between joyent/node and iojs/io.js. We support them both equally. npm, Inc. is not using iojs in production -- yet -- but if iojs users encounter difficulties using npm with iojs, we will treat them as seriously as issues using npm with node. As far as we're concerned, if Homebrew offered a Debian-like /etc/alternatives mechanism, /usr/local/bin/iojs and /usr/local/bin/node would both be acceptable entries there.

Speaking as myself, a longtime Node user, making iojs a keg-only link by default seems backwards. Developers are curious about iojs -- because it has a new V8, it has many features from the draft ES6 standard, it includes the API changes that have been in the long-under-development 0.11 node -- and they want to play with it interactively. Were I to have both installed side-by-side using Homebrew, I'd want node to be the keg-only install used by grunt, bower, etc, and iojs the tool that gets fired up when node gets typed at a terminal prompt, or I use npm -g install to install packages. I don't know how far Homebrew has gone along the path of supporting that kind of behavior, but, that's what I'd want.

[DomT4]

Do iojs and node proper have different default module search paths or will iojs look in e.g. /usr/local/node_modules?

Doing a little test now to see if we can plonk them in separate directories so at least the libs don't clash. Since we handle the npm placement, we can actually control this a little, theoretically. The symlinks to the bin will clash though, and presumably override each other, which could prove troublesome. It is the non-unique desire to symlink from lib/x_modules/xyz to homebrew_prefix/bin that is up there in the most troublesome elements of balancing the clash against usability, alongside using a node => iojs symlink. Those are the two big hiccups around a technical implementation.

Edit - It didn't work. I'll try a new angle.

FWIW, I wish that python, python3, and system Python didn't all attempt to write CLI scripts to HOMEBREW_PREFIX/bin.

Agree with this so very much. If we had more control over where things were scripted into, it would make life a lot easier in terms of reducing conflict, potential break-points, etc. One day, one day.

Using a path like /usr/local/share/iojs/bin for iojs CLI scripts would prevent npm-node and npm-iojs CLI scripts from stepping on each other.

This gives me an idea. Give me like... an hour.

Were I to have both installed side-by-side using Homebrew, I'd want node to be the keg-only install used by grunt, bower, etc, and iojs the tool that gets fired up when node gets typed at a terminal prompt, or I use npm -g install to install packages. I don't know how far Homebrew has gone along the path of supporting that kind of behavior, but, that's what I'd want.

Sadly, this would be a bit of a nightmare to implement at this point in time. It would mean a recompile of everything that shows up under the brew uses node list, and then we'd have the same problem with the shebang not being able to find the correct node in the $PATH. Until iojs surpasses node in popularity and consistent usage, I'm personally a little hesitant to shunt Node into a more submissive relationship.

if Homebrew offered a Debian-like /etc/alternatives mechanism, /usr/local/bin/iojs and /usr/local/bin/node would both be acceptable entries there.

I don't think this is impossible, but it would be a major shift from Homebrew's current way of handling conflict. In many ways, Debian's alternatives mechanism is almost a package manager inside a package manager. Someone would probably have to be lovely and port it to Ruby as well 😉.

[DomT4]

Well, that took longer than an hour. But I've pushed an alternative implementation for discussion in #36039. I considered dumping it in a Gist or something, but if maintainers want to compare the ideas and test them locally and such it's easier to have two PRs to play with instead of one PR, one Gist, or similar.

It fits in with @tdsmith's ponderings further up, which I kinda rolled into my own and went to town. There are probably some choices I've made there that will confuse the heck out of people. Feel free to dump questions on my doorstep and I'll do my best to explain. The implementation isn't perfect, It isn't pretty, It isn't elegant. It is more "Hmm, here's an idea" than it is "This is how we should do this".

[tekacs]

@DomT4
It would mean a recompile of everything that shows up under the brew uses node list

This made me curious - though I'm well aware that 'tap's can change this dynamic, I would note that brew uses node is a list consisting of only 5 formulae:

emscripten keybase pow skinny tegh

Just in case that's something that factors into anyone's consideration (and do correct me if that's the wrong list - uses --devel and --HEAD are the same).

[DomT4]

This made me curious - though I'm well aware that 'tap's can change this dynamic, I would note that brew uses node is a list consisting of only 5 formulae:

Yeah, It's not a huge list right now - At least, that we're aware of. brew uses will only show you what you've tapped, as you've hinted there. emscripten at least also kinda sucks for the bot, It isn't a fun thing to recompile, but primarily, the biggest thing I was concerned about was the shebang situation. With the shebang situation, making any older node-esque formulae keg_only would be a breaking change. Without an easy way to change the shebang, things get a lot less manageable to change dramatically.

There would also have to be small changes to Homebrew's core in addition to any formulae changes, particularly around language_modules referencing usr/bin/env node -e require. In a list of stuff that makes moving Node into a more submissive position difficult I'd place the order as 1) Shebang difficulties. 2) Jiggling around the core code. 3) Rebuilding formulae and testing they can still find the necessary node at run-time.

3 is tricky, but at least is relatively easy to test. IMO, and this is IMO, it is a little premature to talk about effectively replacing Node as the default Node-esque formula just yet. It requires a chunk of work, both here and potentially by upstream devs - and I'm not 100% sure there's a firm demand to kill Node off as a default completely just yet. I kinda live in fear that Homebrew makes these big changes and then get pounded by issues asking what on earth Homebrew has done, heh - Most users won't even see or join these discussions, sadly.

But anyway, that last paragraph is a subjective thing, and evidently from previous posts opinions lead to people getting snapped at and thus, I'd be happier keeping the discussion more technical. If the maintainers want to talk popularity, that ain't my ballgame to field.

[MikeMcQuaid]

I think where I'm at now:

• we install iojs as keg-only.
• we note in the caveats that users should install node to get npm but can have npm use iojs by adding #{HOMEBREW_PREFIX}/opt/iojs/bin to the start of their PATH
• longer-term we either work out a way for iojs and node to have their own npm installed in the Cellar (we used to do this and lots of npm upstream people got very upset with Homebrew) or we wait for some metric indicating that "everyone uses iojs now instead of node" and then we switch which is keg-only and which installs node.

[aredridel]

What problem is having 'npm' not be installed by iojs solving?

If it's the duplication with node, why not just factor that into another file and include it? Can mix in ...

[MikeMcQuaid]

brew install iojs will install npm and then brew install npm will try to install node and fail. This is confusing. brew install npm should continue to work as-is for now (i.e. install node).

It's partly the duplication with node, partly the issues with having two formulae fighting over installing npm and partly it's just not necessary; there's no real reason beyond an idealogical one to insist on having iojs installed and specifically not node installed.

[DomT4]

Incredibly useful upstream list monitoring what's broken in terms of packages and when they are fixed here. Thanks to @timoxley for setting that up.

[markuz-brasil]

LOL this discussion is hilarious.

Just a thought @MikeMcQuaid, but why not have each package being installed individually and have iojs symlink to node only if the symlink doesn't already exits.

After all, npm is not part of node, and since npm doesn't differentiate between iojs and node, it shouldn't install node then. However, if there is no iojs or node, then npm installs iojs (because npm's lead developer said he rather have npm running on iojs by default)

I can not see this situation being fixed without touching all 3 packages in some way.

Botton line, the nodejs, npm and io.js situation is quite unique and so is the solution to this conundrum.

[MikeMcQuaid]

Botton line, the nodejs, npm and io.js situation is quite unique and so is the solution to this conundrum.

I agree. Unless @Homebrew/owners object though I think we'll go with the solution I've specified above until iojs has a bit more traction and then make another call later in the year.

[DomT4]

After all, npm is not part of node, and since npm doesn't differentiate between iojs and node, it shouldn't install node then.

If you're proposing moving to shipping an npm formulae here, 👎. See #3762, #22408, #27479 and #28075.

I can not see this situation being fixed without touching all 3 packages in some way.

Various implementations discussed are keg_only without npm, adding a firm conflicts_with or as Tim floated earlier and I drew up an example for in #36039, moving it into share and using some exec script dancing to facilitate there being no automatic clashing between node and iojs at all - At the expense of asking the user to juggle their $PATH around as desired to fit whichever node-esque formulae they wish to use at the time.

It's just trying to find the balance between convenience and not causing users or the maintainers here endless pain I guess 😸.

[vitorgalvao]

Going back to @othiym23’s comment

making iojs a keg-only link by default seems backwards. Developers are curious about iojs

I agree the proposal to cripple the iojs formula seems really wrong. When you say

until iojs has a bit more traction and then make another call later in the year.

That is stopping iojs traction. Having official homebrew support would be a big deal towards making sure it’d have a faster and wider adoption, as popular tools (like homebrew) have a lot of power (both for and against) in that regard.

[MikeMcQuaid]

I agree the proposal to cripple the iojs formula seems really wrong.

Let's stop the conversation here, please. No-one is crippling anything. The way node, npm and iojs currently play together means that we need to be careful to avoid breaking things that will create a lot of extra work for us and upstream developers. No @Homebrew/owners have objected to my plan above so that's what I'll be doing and getting this merged next week.

[MikeMcQuaid]

Merged the version in #36193 which met the requirements I'd mentioned previously. Well done to @bcomnes, @DomT4 and @aredridel for all contributing parts to get this merged.

To some people in this thread and those who have indulged in namecalling on Twitter: consider whether your actions helped motivate or demotivate the Homebrew maintainers (all of whom work in their spare time for free, I've personally been on vacation away from home for the majority of this thread) to work on fixing issues that may arise in future with iojs.