Working with nvm, nvmw and similar installation managers about node

[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 [email protected]. 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.

[Fishrock123]

@bnoordhuis we'd definitely want to have shasums directly along side of them, imo.

[bnoordhuis]

@Fishrock123 Yes, agreed.

[mostman1043]

As someone responsible for the engineering team of a software company that is built on top of Node - this right here is what will get us to test out and contribute to io.js. If anyone needs any feedback or help getting this going, I'm raising my hand.

[caineio]

Hello!

I am pleased to see your valuable contribution to this project. Would you
please mind answering a couple of questions to help me classify this submission
and/or gather required information for the core team members?

Questions:

1. Issue-only Does this issue happen in core, or in some user-space
   module from npm or other source? Please ensure that the test case
   that reproduces this problem is not using any external dependencies.
   If the error is not reproducible with just core modules - it is most
   likely not a io.js problem. Expected: yes
2. Which part of core do you think it might be related to?
   One of: debugger, http, assert, buffer, child_process, cluster, crypto, dgram, dns, domain, events, fs, http, https, module, net, os, path, querystring, readline, repl, smalloc, stream, timers, tls, url, util, vm, zlib, c++, docs, other (label)
3. Which versions of io.js do you think are affected by this?
   One of: v0.10, v0.12, v1.0.0 (label)

Please provide the answers in an ordered list like this:

1. Answer for the first question
2. Answer for the second question
3. ...

Note that I am just a bot with a limited human-reply parsing abilities,
so please be very careful with numbers and don't skip the questions!

In case of success I will say: ...summoning the core team devs!.

In case of validation problem I will say: Sorry, but something is not right here:.

Truly yours,
Caine.

Responsibilities

1. indutny: crypto, tls, https, child_process, c++
2. trevnorris: buffer, http, https, smalloc
3. bnoordhuis: http, cluster, child_process, dgram

[smikes]

1. yes
2. other
3. v0.12

Marking this as "v0.12" because it would be good if this were stably implemented < v1.0.0, to facilitate testing and deployment of v1.0.0-alpha releases; please relabel if appropriate /cc @bnoordhuis

[caineio]

...summoning the core team devs!

[ljharb]

Awesome - if someone could put up example content anywhere for me to play with, that pointed to a real installation URL (of any version), then I could get something out prior to the iojs release that would, for everyone else, start working once a release came out. Otherwise there'll be a bit of lag time while I do testing :-)

[cjihrig]

Is the format of the file(s) the only thing in question? Can you point the files to joyent/node installations for the time being for testing?

[Fishrock123]

@mikeal can this be on a tc agenda please?

[mikeal]

@Fishrock123 we don't have any control over this do we? this is up to the nvm maintainers. Once we have a release I'll send them a PR myself if I have to :)

[gkatsev]

@mikeal the thing that can go on the agenda is whether iojs will provide a file with the builds and urls to builds in the following format: #40 (comment)

[mikeal]

ah, ok. adding to tc agenda.

[Fishrock123]

@gkatsev We'll be doing some format of that anyways.

@mikeal it would be nice to have an official one imo

Edit:

More specifically it would be nice to have something builtin where users can easily upgrade versions without having to install anything extra.

I know this is feature creep, but it seems worthwhile.

Maybe not TC for now then.

[ljharb]

@mikeal I am the nvm maintainer, and you won't need to send a PR if I have the right info available to me and if I won't have to rewrite everything to support iojs :-)

[crueber]

@ljharb That would be awesome. I would dig not having to a whole lot to do but hit an nvm install. :)

[JJ]

👍 1:

[rvagg]

After discussion in the TC meeting, see #144, the outcome is:

• TC wants to make it easy for version managers / installers
• The details are not necessarily the responsibility of the TC to bikeshed right now so the mechanics of the distributions, including catalog files will be passed to the build team for now and will come back to the TC prior to formal release for acceptance.

See nodejs/build#22 where I've pulled in a bunch of you already, we can continue discussion there but perhaps wait until we have started work on something and then we can iterate to make sure everyone is happy.