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.

[bnoordhuis]

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

I think that can be arranged. Do you need something like a .txt with file paths or would a base URL + predictable path work (e.g. https://iojs.org/download/x.y.z/iojs-x.y.z.tar.gz)? I guess you'd still need a list of released versions.

[smikes]

I would like to have two resources at static locations --

1. a text file which documents all available releases
2. a text file which identifies the latest version, or (if there are multiple release streams eg stable, canary) the latest in each release stream

Item 2 is useful in a brew doctor type context, where I want to do a quick request and let the user know if an upgrade is available, while Item 1 is what a fully-capable tool like nvm wants.

Since nvm is a shell script, simpler is better. A parseable list of each tar.gz would be ideal. Notionally:

$ curl https://iojs.org/download/all-versions.txt
https://iojs.org/download/1.0.0-a1/iojs-1.0.0-a1.tar.gz
https://iojs.org/download/1.0.0-a2/iojs-1.0.0-a2.tar.gz
https://iojs.org/download/1.0.0/iojs-1.0.0.tar.gz
$ curl https://iojs.org/download/latest-versions.txt
stable: https://iojs.org/download/1.0.0/iojs-1.0.0.tar.gz
latest: https://iojs.org/download/1.0.0/iojs-1.0.0.tar.gz
canary: https://iojs.org/download/1.0.0/iojs-1.1.0.tar.gz

Do those sound like reasonable URLs? https://iojs.org/download/all-versions.txt and https://iojs.org/download/latest-versions.txt

[ljharb]

What @smikes is suggesting would work perfectly, especially because it's easily curlable and parseable.

[alexgorbatchev]

may I suggest the following:

$ curl https://iojs.org/download/all-versions.txt
1.0.0-a1: https://iojs.org/download/1.0.0-a1/iojs-1.0.0-a1.tar.gz
1.0.0-a2: https://iojs.org/download/1.0.0-a2/iojs-1.0.0-a2.tar.gz
1.0.0: https://iojs.org/download/1.0.0/iojs-1.0.0.tar.gz

[SomeoneWeird]

What about a json blob with a latest key?

[keithamus]

What about replicating/emulating NPM's JSON structure? Seems to work well for them. Something like:

{
    "dist-tags": {
        "latest": "1.0.0",
        "beta": "1.1.0-beta"
    },
    "versions": {
        "1.0.0": {
            "dist": {
                "shasum": "2f246aeae428f07feaceb8d39a2e3870a978c9f8",
                "tarball": "http://iojs.io/download/1.0.0.tgz"
            }
        },
        "1.1.0-beta": {
            "dist": {
                "shasum": "910e639e7f523e8fa28047307aecfd89fe6a55a7",
                "tarball": "http://iojs.io/download/1.1.0-beta.tgz"
            }
        }
    }
}

[ljharb]

JSON is much nicer but much more difficult to parse on a shell. I'm all for a JSON option but please let's also provide a straight plain text option?

@alexgorbatchev's modification to all-versions.txt is better 👍

[smikes]

JSON is much nicer but much more difficult to parse on a shell. I'm all for a JSON option but please let's also provide a straight plain text option?

The challenge of a version manager is it has to work when there is no node installed. That's bad enough with nvm running under a POSIX-y shell, but think how hard it must be for nvmw who have to do it under CMD.EXE or (if lucky) powershell.

Plain text for now. JSON for 1.1 or 2.0

@alexgorbatchev's modification to all-versions.txt is better 👍

Also 👍 to version: url

[bnoordhuis]

Nominating for the v1.0.0 milestone. I suggest a simple line-based $version $url because it's easy to parse.

/cc @Fishrock123 - I expect that the list will have to be updated manually for now. Ideally, it's auto-generated but it's unclear to me how that would work. A cron job running on dist.iojs.org? Generated by the CI when releasing? TBI.

[naholyr]

How does nvm work for node already? Would not the best way to make life easier for @ljharb be to just provide the exact same files, same paths, same formats, with just a different domain name?

[ljharb]

That would indeed make it insanely trivial for me to add iojs support to nvm. However, the current method for nvm ls remote of scraping a webpage and parsing stuff out of it is atrocious, and I'd love to move away from that.

[naholyr]

Oh OK didn't know that ;) then 👍 for @alexgorbatchev 's version: url very easy to parse. May I propose = instead of : as separator? It would then become simple ini data, which is fast & safe & easy to parse in any language.