Repository navigation
Working with nvm, nvmw and similar installation managers #40
Description
Activity
👍 for this one.
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.
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.
See also: node-forward/discussions#6
👍 to this entire discussion
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.
@arb What's the motivation for adding versioning complexity directly to core itself? I find
nvmworks great.Also +1 to
nvm,n, etc support.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.
Awesome! 👍
There are two topics here:
- making
io.jswork withnvm,nvmw, etc.. - including one (or more) of
nvm,netc. with official distribution packages ofio.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 theio.jsroadmap. (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
nvmto put together a PR for theio.jsrepositories, once they are established?- making
@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.12and later (the "versions" subdirectory) to make sure thatiojsversions end up in a subdirectory as well - but we can bikeshed these things on thenvmrepo.Currently
nvmlists versions by scraping the nodejs.org website, which is also where it downloads binaries. Will there be a reliable source for listingiojsversions, and also downloading binaries?Maybe we can expose an api as a function of the build system on iojs.org?
@ljharb I think there will be a better listing, eventually: https://github.com/iojs/build
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
iojsis planning to follow semver, there's that, at least.33 remaining items
@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.
👍 1:
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.
- added a commit that references this issue
on Jan 20, 2015 - added a commit that references this issue
on Apr 13, 2019
This is intended as a placeholder and heads-up.
In the transitional period (while
io.jsis 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 bothio.jsand node. Makingio.jseasy to install via tools likenvmwould ease that.nvm maintainer @ljharb says this here ( nvm-sh/nvm#590 (comment) )
So that's a good goal.