search

nodejs / TSC

The Node.js Technical Steering Committee
591 stars 133 forks source link

Investigate moving `nvm` into the foundation #96

Closed ljharb closed 7 years ago

ljharb commented 8 years ago
Fishrock123 commented 7 years ago

This, I guess, is the "Ruby" approach. A separate utility is installed to govern the version of the runtime. Would this approach constitute a change in packaging, such as when I go to nodejs.org and download "node", will I be getting the version manager, which will then install node? Or will the packaging remain as it is

I think the installers would ship with a version manager, but the package downloads would definitely still remain.

rvagg commented 7 years ago

I'm not OK with just opening the doors here and suddenly inheriting a bunch of version managers. I'd really like to hear what the consistent story is and how people see this evolving other than just us having a bunch of maybe-maintained projects that we have to deal with issues on. It could end up like node-gyp where nobody takes strong responsibility but it's a magnet for people filing issues. I can maybe get the case for nvm but we have no info so far on whether nvm is even the most used one out there (minis Travis usage) and what other version manager maintainers want to do.

It's precisely because nvm exists in a competitive ecosystem that opening the doors to it will open the doors to even more projects and we'll have set a precedent that will be hard to walk back on. Count me as one of the people not convinced we should do this because of this fact. node-gyp was much easier to justify, there's basically no competition and it wasn't being actively maintained yet was relied upon by most Node users. It's created a burden on us but it's pretty important for Node's success. I'd like someone to make that case about nvm and what the strategy is beyond initial acceptance.

I'm asking for more investigation simply because I don't see a convincing case here and I'm pretty sure I'm not the only one. @Fishrock123 and @jasnell if you think otherwise and believe this is a no brainier then let's push for a vote. As it stands I'm a -1 because of all of the uncertainty, even down to who is going to drive this and invest their already overstretched time in it?

ljharb commented 7 years ago

fwiw, I've laid out a basic road map for nvm and added to it here.

joshgav commented 7 years ago

I wrote a gist to address @rvagg's concerns and explain why we'd want to manage an environment manager in core: https://gist.github.com/joshgav/7f08a8ee8680f90a58ba23c7fbeeb6f1.

I think it may provide enough to unblock us and start the next phase of coordination between the several current maintainers and implementations in a shared workspace/repo.

Thoughts?

marcelklehr commented 7 years ago

Creator of nodist here. Even though I, as I'm sure do many of you, have limited time, I would love discussing and working towards a convergence of version managers across operating systems and switching mechanisms!

coreybutler commented 7 years ago

@marcelklehr - Any interest in having a separate chat about potential collaboration? I think nodist & nvm-windows are the only projects written in Go. As I've mentioned a couple of times in this thread, I'm working towards a cross-platform edition... but I'm also fairly pressed for time.

brodycj commented 7 years ago

I would rather see a version manager that supports both Windows and non-Windows platforms and is primarily in JavaScript, such as https://github.com/jasongin/nvs (thanks @joshgav).

ljharb commented 7 years ago

@brodybits long term, that's probably the best direction, but there needs to be lots of iteration on featuresets so as to address use cases, and provide migration paths.

joshgav commented 7 years ago

The TSC reached consensus to start a discussion group bringing together the various maintainers and stakeholders for version management tools for Node - basically everyone on this thread 😄 - with a goal of quickly providing recommendations and a roadmap for version management in core. Items this group should tackle now include if/how to converge on a single tool, if/how to distribute or bundle with Node, how to support all platforms, etc.

The TSC would like us to have this roadmap ready to discuss by their next meeting, Thursday 11/17. Then they can make a decision on whether to accept "version management" as one of core's responsibilities.

To this end, we now have a repo at https://github.com/nodejs/version-management. I'll set up the boilerplate stuff there and a doc or two and look to you all to open issues etc. for further discussion.

Thanks!!

marcelklehr commented 7 years ago

@coreybutler we could meet here: https://gitter.im/marcelklehr/nodist - although I think, it might be better to put our efforts into the new WG for now, at least until it has reached an outcome and the TSC has reached a decision.

ljharb commented 7 years ago

fwiw, I think any long term project should be written in JS if possible to maximize contributors and accessibility, but that can be part of the discussions we have.

coreybutler commented 7 years ago

@marcelklehr - agreed... the new repo was setup right after I made that comment. See you in the WG!

joshgav commented 7 years ago

To help in continuing this thread, I'm bringing over this discussion which followed the Version-Management Discussion Group Meeting on 2016-12-01.

What about nvm being in the Foundation?

@ljharb > why only one? This makes no sense to me. Bringing in two, or three, in no way is a slippery slope to "all".

@joshgav> @ljharb the key new understanding we reached in our discussion Thursday was that any project in the Foundation needs to be actively supported by the Foundation. That means at least engineers maintaining and updating it, but more than that indicates some degree of assumed responsibility for us here in core; perhaps to address bugs and security issues, perhaps something else. /cc @mikeal @rvagg for further thoughts.

Based on that understanding it's probably not sustainable to support more than one in core, so we want to be conscientious about what that one is.

Does that help explain why it seems "only one in the Foundation" should be our goal? Do you think we could support more?

ljharb commented 7 years ago

@joshgav I absolutely think we can support more, because more are already being supported - just not by the foundation. Adding projects to the Foundation does not move the total maintainence burden, it lessens it because more people might be able to help lighten the existing maintainers' load.

If nvm enters the foundation, I'm not going to suddenly alter the amount I maintain it - nvm being in the foundation adds, initially, precisely zero cost to the Foundation itself.

Even now, though, not in the foundation - if nvm suddenly needed maintenance I was unable to provide, the Foundation would probably have to step in to serve those users and provide graceful migration instructions anyways - because so many node users already rely on nvm, either directly or via travis.ci - so whether it lives in the foundation or not doesn't impact how much work the foundation might potentially have to do.

mikeal commented 7 years ago

A few things that are hard to get from just notes.

  1. The Node.js Foundation is backing away from being an umbrella. 1.1. Projects in the foundation are those directly tied to core. 1.2. Concern about "blessing" a project and ruining ecosystem competition is a big concern as well.
  2. The Node.js Foundation is partnering with the JS Foundation to make it a great home for Node.js projects. 2.1. The JS Foundation is setup, structurally speaking, to be an umbrella. 2.2. The JS Foundation can provide better support for projects as that is their primary mission, where ours is Node.js itself, and we can help the JS Foundation to support projects critical to Node.js.

If the maintainers of nvm think it needs to go into a foundation then we believe them. The question of entering the Node.js Foundation was greater than just "does the project need a home" and the answer from the versioning group seems to be that it shouldn't go into the Node.js Foundation but if the maintainers need a home for it the JS Foundation is an option.

I'm willing to help get it into the JS Foundation and support it. We aren't trying to pass the buck, we have a partnership so that we can continue to support important projects that just don't belong, structurally speaking, in the Node.js Foundation.

ljharb commented 7 years ago

@mikeal the JS foundation doesn't make much sense to me for a non-JS project, but I'm fine with putting it there if that's what the node foundation has decided - although I can't understand why it would want to "back away" from being an umbrella, since that's what foundations are for imo.

mikeal commented 7 years ago

@ljharb projects that improve the web or the overall JS ecosystem are a good fit in the JS Foundation. Appium is a good example which has code and bindings in a bunch of languages but is fundamentally for testing the web.

We are still working on better documentation on how the Node.js Foundation is structured but if you compare it with the JS Foundation you'll see why it's a better fit.

The Node.js Foundation was started as a home for Core and for merging io.js. The initial structure has solidified somewhat and our attempt at re-structuring as an umbrella didn't work. The JS Foundation learned from what we did and designed a much better structure for bringing in and supporting many projects. They also adopted our governance ideas, in some cases verbatim, so they've been able to take ideas from our success as well as our failures in terms of structure.

ljharb commented 7 years ago

If the JS Foundation has a better structure, could the Node foundation not adopt it? Or perhaps should the Node Foundation be renamed to the Node Core Foundation? Will express and so forth be moved to the JS Foundation?

mikeal commented 7 years ago

@ljharb it has proven difficult to adopt structural changes while also supporting Core, its contributor growth, and the growth of the Node.js user base. We have a lot to do already and all under one roof, the idea of taking on more concerns a lot of people who think it will lead to a lack of focus.

Express can join the JS Foundation if that is their preference. They have some autonomy so we can't make them join another foundation if that isn't what they wish.

creationix commented 7 years ago

In my opinion, the current real value of nvm is the CLI interface that has become hugely popular. I've seen some cloud providers (such as redhat openshift) even write nvm clones that mirror a subset of the functionality.

For cross-platform support I agree that something written mostly in JS with shims implemented in various shells (sh, fish, cmd, powershell, etc) would be ideal technically.

There were still npm competitors when it became part of core, but it was obvious that npm was the de-facto standard for most people. As far as I can tell nvm has reached similar status, but getting hard numbers is hard. I've just been surprised the number of infrastructure places I've seen it used or cloned.

joshgav commented 7 years ago

To wrap this conversation per the last TSC meeting, the recommendation of the version-management group, which brought together @ljharb and authors of other popular version managers for Node, was that Node core should not bring in and support a version manager without first defining requirements for such a tool and ensuring whatever is brought in meets those requirements. The TSC accepted that recommendation.

On the other hand, the TSC agreed that the version-management group created for this discussion should remain active and continue to seek consensus on those requirements; and once they are defined may recommend that the Foundation support an updated nvm or other project.

jasnell commented 7 years ago

Given the most recent status update, and given that the investigation is underway, there's no reason to keep this issue open. Closing. If anyone feels it is necessary to keep it open, please reopen.

DanielSundberg commented 7 years ago

Where can I follow this discussion now when this issue is closed?

Trott commented 7 years ago

@DanielSundberg https://github.com/nodejs/version-management (although it looks like there hasn't been much activity since December)

Trott commented 7 years ago

@DanielSundberg Also, perhaps, specifically this: https://github.com/nodejs/version-management/issues/10