Working with nvm, nvmw and similar installation managers

[smikes]

This is intended as a placeholder and heads-up.

In the transitional period (while io.js is gaining acceptance, node has a huge install base, and people are sorting out which binary they are going to use), package authors will need to test against both io.js and node. Making io.js easy to install via tools like nvm would ease that.

nvm maintainer @ljharb says this here ( nvm-sh/nvm#590 (comment) )

If the community starts moving in a major way towards any given fork of node, and if that fork provides the same installation methods that node does (binaries and source), then this project should be able to easily support it, and I'd intend to do so.

So that's a good goal.

[jaydson]

👍 for this one.

[arb]

To that same effect, I would like to see version switching (of io.js) build directly into the run time. Needing a separate tool to version switch is just added overhead. I'm pretty sure anyone doing work on node/io.js has either nvm or n already installed so making one pack-in solution seems like a good idea to me.

[gkatsev]

Not sure we'd want to have such a thing built into core. Perhaps the binaries can ship with a specific tool, a kin to how npm ships with it.

[Fishrock123]

See also: node-forward/discussions#6

[therebelrobot]

👍 to this entire discussion

[ljharb]

Please note that this may apply to environment variables such as $NODE_PATH, although that's an easier thing to handle, as well as installation methods and relative file paths within the installation directory.

For another +1, if nvm adds iojs support, then travis-ci gets it too with no extra work on their end.

[kenperkins]

@arb What's the motivation for adding versioning complexity directly to core itself? I find nvm works great.

[kenperkins]

Also +1 to nvm, n, etc support.

[arb]

If the versioning is built in, deployments and authoring would probably become easier you would have consistency with how to change versions across different environments.

My main thought was that it's just a tedious chore to ALWAYS have to set up some kind of versioning manager. We all basically need it anyway, why not build it in/ship the binary with it already included like npm.

[sergiolepore]

Awesome! 👍

[smikes]

There are two topics here:

1. making io.js work with nvm, nvmw, etc..
2. including one (or more) of nvm, n etc. with official distribution packages of io.js.

I am in favor of both of those, but I think we should talk about them separately. Item 1 will be useful for testing early releases -- such as io.js@1.0.0-a1. Item 2 is more like a post-1.0.0 feature from what I understand of the io.js roadmap. (Item 2 also offers more opportunity for bikeshedding...)

I propose that discussion of item 1 stays here and discussion of item 2 goes to node-forward/discussions#6 (which I was not aware of when I created this issue, even though I commented on that issue a month ago...)

@ljharb Can I assume you don't mind me starting to dig around in nvm to put together a PR for the io.js repositories, once they are established?

[ljharb]

@smikes Not at all, it's appreciated! Multiple smaller PRs preferred, and I'll want to follow the cowpath I've built for node 0.12 and later (the "versions" subdirectory) to make sure that iojs versions end up in a subdirectory as well - but we can bikeshed these things on the nvm repo.

Currently nvm lists versions by scraping the nodejs.org website, which is also where it downloads binaries. Will there be a reliable source for listing iojs versions, and also downloading binaries?

[kenperkins]

Maybe we can expose an api as a function of the build system on iojs.org?

[gkatsev]

@ljharb I think there will be a better listing, eventually: https://github.com/iojs/build

[smikes]

Will there be a reliable source for listing iojs versions, and also downloading binaries?

This is exactly the sort of thing I want to discuss here. No idea if planned, sounds like a good idea though. ;-)

Since iojs is planning to follow semver, there's that, at least.