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

Support multiple activated versions with hierarchical preference #153

Open
gschaffner opened this issue Mar 16, 2020 · 4 comments
Open

Support multiple activated versions with hierarchical preference #153

gschaffner opened this issue Mar 16, 2020 · 4 comments
Projects

Comments

@gschaffner
Copy link

gschaffner commented Mar 16, 2020

It would be useful if users could specify multiple versions to have active at once like you can with pyenv. See here for documentation (Ctrl+F "advanced").

For example, consider if a package that provides ~/.nodenv/versions/11.1.0/bin/program is installed but no program is installed to ~/.nodenv/versions/12.0.0/bin/program. Setting nodenv global 12.0.0 11.1.0 could allow the node and npm shims to call Node 12.0.0 while allowing the program shim to fall back and call 11.1.0 since program is not present at ~/.nodenv/versions/12.0.0/bin/program.

Thanks for the great work!

@jasonkarns jasonkarns added this to Triage in nodenv Apr 1, 2020
@jasonkarns
Copy link
Member

I'll have to look into the code to see how complex the solution is.

A related feature I've been planning to take on (both for nodenv and rbenv upstream) is to allow the shims to "fall through" whenever an executable doesn't exist within the active version. So instead of an executable being invoked from another nodenv version, the call is invoked as if the shims didn't exist, and thereby invoking the next available match from PATH. This isn't quite as sophisticated as the feature you suggest here, but I imagine it probably covers a good majority of the use cases.

@gschaffner
Copy link
Author

Thanks for looking into this!

If the pyenv implementation isn't too complex, I think it would be preferred to fall through as the fall through feature is really just a subset of the pyenv feature: fall through to the next available in PATH (presumed the system node install) would be equivalent to nodenv global 12.0.0 system.

The fall through feature definitely sounds simpler to implement. However, it might require an additional setting for users as part of .node-version. E.g. what if I have .node-version files in ~/a and ~/b, and I want fall through when working in ~/a but no fall through in ~/b? If there isn't a setting in .node-version for it, the only way to disable fall through on a per-directory basis would be to shim ${cli-program-installed-to-system-node} later in PATH than nodenv shims it, and on a per-directory basis. That just sounds like a re-implementation of nodenv which would make PATH messy.

The example scenario of ~/a and ~/b above is realistic I think. For example, you want fall through in ~/a in order to access CLI programs installed to system node. You want don't want fall through in ~/b in order to not accidentally call a CLI program from the wrong node version.

The pyenv solution is elegant in that it's a superset of fall through and it wouldn't require adding a fall through toggle in .node-version (instead, .node-version could support multiple versions, one per line like with pyenv).

@jasonkarns
Copy link
Member

This is the related thread which started my thinking along this line in rbenv a while back: rbenv/rbenv#865

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

No branches or pull requests

4 participants
@jasonkarns @gschaffner and others