Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which Switching Scopes to support by an official solution? #4

Open
marcelklehr opened this issue Nov 4, 2016 · 18 comments
Open

Which Switching Scopes to support by an official solution? #4

marcelklehr opened this issue Nov 4, 2016 · 18 comments

Comments

@marcelklehr
Copy link
Member

Before we dive into discussions on which language/framework to use, I think we should have a clear set of features that we want to offer.

@marcelklehr
Copy link
Member Author

There's quite a few different scopes for setting a version requirement, that I can think of:

  • system-wide
  • per user
  • per terminal
  • per directory

pro UX

I've found per terminal and per directory to be the most useful, as per-terminal is imperative-ish but temporary (if you want to try your app with a different version), while per-directory is declarative and persistent (the default version per app). I think the great advantage of per-directory settings is that you don't need to remember to change your global node version when your change to another project, the switching is automatic, but defined in a declarative fashion per directory, just like your dependencies, and your build/test scripts, (possibly in the package.json, where there is already a corresponding field). IMO that's very powerful.

pro simplicity

However, the downside of this feature is that it's not easy to implement consistently across operating systems. It could also be argued that, rather than wait for a high-end solution to be built, it's better to work on a simple solution that may require more cognitive load from the down-stream developer.

I see both sides while leaning more towards pro UX

@digitalinfinity
Copy link

@jasongin put together a table at https://cdn.rawgit.com/jasongin/cf9f64dd2739d78412bb9410701bf166/raw/69d48e0774f43280763eb7bb7175e930ab3e9f33/NodeVersionManagers.html comparing the various scopes settable by current version managers. It might be helpful to this discussion.

@jasongin
Copy link
Member

jasongin commented Nov 4, 2016

the downside of this feature is that it's not easy to implement consistently across operating systems

It's not so bad. For nvs I'm currently developing automatic per-directory switching. (It already supports the other 3 scopes.) For Windows PowerShell I've got it working now by hooking PowerShell's prompt function. I plan to implement the equivalent for POSIX using the same approach as nodengine. Windows Command Prompt does not offer any integration point though.

Of course any automatic switching feature should be optional, as not everyone wants things to happen without an explicit command.

@marcelklehr
Copy link
Member Author

@jasongin Interesting! I implemented per-directory switching via a binary shim in nodist, because I didn't want to / couldn't hook into cd.

@coreybutler
Copy link
Member

This is a good breakdown. The first two scopes seem to be the common denominator. The third and fourth seem more a matter of opinion.

I also see the value of both sides, but I lean pro simplicity.

@ljharb
Copy link
Member

ljharb commented Nov 6, 2016

@coreybutler nvm is entirely the third, so in no way is it just a "matter of opinion".

In fact, the second is the one that nobody seems to be really addressing currently - n is systemwide (across users), nvm is per-shell (within a user), nave is per-subshell (within a user). The fourth is dealt with any non-systemwide solution that includes auto version switching on cd (which you can do with nvm, but is not done by default to avoid being instrusive)

@coreybutler
Copy link
Member

@ljharb - I respectfully disagree. Before version managers existed, the only choices were the first two. In other words, you don't need 3 & 4 to accomplish version management. nvm-windows and n prove this by lack of 3 & 4. I'd argue Tim created the 3rd & 4th when he released nvm.

nvm-windows does support per-user, but defaults to systemwide. It's an option in the installer.

@jasongin
Copy link
Member

jasongin commented Nov 7, 2016

@coreybutler I think the popularity of nvm (and nave to a lesser extent) proves there is a very significant user base who prefer (or need?) to have per-shell versioning.

I don't think a single switching mechanism or just one (or even 2) of those four scopes will ever satisfy everyone's needs. I'd suggest that any converged solution we work on must cover at least the first 3 of those scopes, and ideally all 4.

@ljharb
Copy link
Member

ljharb commented Nov 7, 2016

@coreybutler you may be right that the creation of nvm created the third and fourth - but they are now, unarguably, absolutely critical use cases that must not be ignored.

@coreybutler
Copy link
Member

@ljharb - I'm not suggesting we ignore options 3/4, I'm suggesting they be optional features that can be turned on. In other words, the default should only enforce what's actually necessary to perform version management, with the option to turn on extra features.

@ljharb
Copy link
Member

ljharb commented Nov 7, 2016

There are a number of benefits with having the default be per-shell instead of being systemwide.

@marcelklehr
Copy link
Member Author

I agree that strictly speaking "you don't need 3 & 4 to accomplish version management" or version switching. However, I believe that a version manager (just as any tool; especially an official one) should address the needs of its users.

To elaborate on why I'm leaning towards UX: I'd argue that while downstream developers might want a way to somehow quickly uninstall one and install another version when they work on another project (which is equivalent to 1), what they actually need is a way to use multiple versions at once or even set a default version per project.

I also agree that 1/2 make sense in certain cases and should thus be part of an official solution, however I think 3/4 should be provided as well.

@ljharb Could you elaborate on the benefits of 3 to be the default?

@rmechamatadobe

This comment has been minimized.

@ljharb

This comment has been minimized.

@rmechamatadobe

This comment has been minimized.

@ljharb

This comment has been minimized.

@rmechamatadobe

This comment has been minimized.

@coreybutler

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants