Implements nvm which

[danielb2]

No description provided.

[ljharb]

nvm_version system is system - might be simpler to just always send $INPUT through nvm_version?

[ljharb]

• assuming that $INPUT is defined, of course

[danielb2]

I did it this way to allow for nvm which with no arguments. The idea is that it would show the default.

Do you think it's a bad idea? It was more work than it was worth :/

[ljharb]

Conventional behavior for all the nvm commands is that when a version isn't specified, it follows these steps in order:

• call nvm_rc_version and if [ -n "$NVM_RC_VERSION" ], then use that.
• use nvm alias default if set
• error out and show help

[ljharb]

This is great! It would also be ideal if nvm which had the same "use default, or fall back to .nvmrc"? Currently, nvm which appears to print my system version rather than printing help.

[danielb2]

@ljharb did you have any more concerns?

[ljharb]

this nvm deactivate means that nvm which system will end up deactivating the current shell. I think you want to remove deactivate here, and change the below line to echo $(nvm use system && echo dirname $(which node))?

[danielb2]

What's the purpose of the nvm use system in your suggestion? I wouldn't want to change anything since the purpose of nvm which is just to display information

[ljharb]

If I have a version activated, the subshell will also have that version activated - nvm use system in the subshell will deactivate nvm in the subshell without affecting the parent/current shell.

[ljharb]

Sorry for the delay; I was out of town. In addition to the comments above, could you add test coverage for nvm which system, nvm which with an .nvmrc file, nvm which with no .nvmrc file, and nvm which some_alias, and nvm which uninstalled_version?

Also, this will need to be freshly rebased on top of master.

Thanks!

[ljharb]

Per the previous comments - with a system node of 0.10.33, nvm use 0.9 && nvm which system would return 0.9.x, unless as the subshell command you have "$(nvm use system && dirname "$(which node)")"

[danielb2]

ok, thanks

[danielb2]

FYI, the tests files with spaces are a real pain. Have you considered using underscores instead?

[ljharb]

The file names are used in the test results, so underscores would make those really unreadable.

[danielb2]

Should be easy to substitute the underscores for spaces when printing the output. Either way, it's a trade-off I'd do. It's been really annoying to deal with the files with spaces for me.

[ljharb]

This line should be echo "$(nvm use system 2>&1 >/dev/null && dirname "$(which node)")".

Note the removed "echo", the suppression of nvm use system output, and the double quotes around paths that could contain spaces.

[ljharb]

Other than this one comment, and adding additional tests, this works perfectly, thanks! Your persistence is appreciated.

[danielb2]

Hm, I still think that just typing nvm which should reflect the node file which gets executed if I just type node

Right now it uses the rest of the default behavior and checks for .nvmrc and bails out if it's not found.

[ljharb]

My position is that since it starts with nvm it should behave the same as the other nvm commands.

[danielb2]

Let's compare nvm which with nvm ls

Typing nvm ls lists all installed versions of node

The way you're asking me to do nvm which is that it should print an error if there's no .nvmrc

What users expect is important too. And I expect nvm which to work similar to nvm ls, showing the current node which would be executed.

Remember the purpose of this PR. It's so that it can be used with other shells and be free standing.

So if a user does nvm use 0.10 and the executing wrappers need to know how to modify the PATH, then I think nvm which would be the most transparent method to use to get the path to node which is used. How did you imagine this interface to work?

[ljharb]

nvm current does show the current node to be executed - nvm ls isn't quite comparable because it lists versions.

When a .nvmrc is present, that's the version of node that would be executed - so in that case, nvm which imo should absolutely be returning that node path. If it doesn't, then this one part of the tool simply doesn't support .nvmrc, which seems unacceptable to me.

In the case of no .nvmrc, I'd be fine with nvm which returning which node - but in that case, why would it add any value over which node? In other words, if the PATH is not yet modified, then how would nvm which know which node path to return? If it's already modified, then why wouldn't the wrappers just do which node?

[danielb2]

In the case of no .nvmrc, I'd be fine with nvm which returning which node - but in that case, why would it add any value over which node?

The goal is to set the PATH. How would which node return the same thing as nvm which without some script setting the PATH to include that node?

[ljharb]

Right - when the PATH is not set, nvm current can't know to return anything - all the info it has comes from either the PATH, .nvmrc, the command line arguments, or the default alias.

How could nvm which select a version of node without one of these pieces of information?

[danielb2]

Let's start over because I feel we're not getting anywhere now.

The current limitation of nvm is that it does not play nice with other shells.
We discussed and agreed that implementing nvm which would allow to fill in this gap, and even make it possible to be standalone from bash itself.

The idea is to have a wrapper for shells. Let's take fish, my preferred shell. If I use nvm install 0.10 to install node. I set it as my default. When I open a new shell instance in fish next time, I expect the default to stick.

I imagined calling nvm which from the fish wrapper to get the PATH to the default (however that is set).

What is your thinking?

[ljharb]

Thanks, you're right we were going in circles :-)

OK, so you're saying that in a shell where nvm is already active and a node version selected, you want to get the PATH to node so you can pass it to a wrapper, for example, a fish shell wrapper.

In that context, why do you need an nvm command? Wouldn't which node always provide the path you want?

(Note I'm not saying that nvm which x isn't useful, we're just talking about the no-version use case here)

[danielb2]

Not quite. There's no active nvm because it's not a bash shell. This would be a fish shell that needs to get nvm to be active through a wrapper shell. The wrapper shell is the one which makes use of nvm which.

[ljharb]

I meant in the wrapper shell (bash, eg) that is used to call the wrapped shell (fish, eg). Within the wrapper shell, nvm is activated normally, so which node should work there, shouldn't it?

[danielb2]

Wow it got hairy :)

At this point I would say that nvm is just a script, albeit written in bash. It's not a shell as such (isn't used as one). There wouldn't be any need for nvm to alter the PATH internally. As it stands, yes it would work, but I don't see that being necessarily the case if this is where nvm decides to go.

[ljharb]

Right - but nvm only works in the context of a shell whose PATH is/can be modified, since it's a sourced shell function, not a binary

At any rate, nvm which x is something that unarguably should go in. The only open question is, what should nvm which do? It seems we've got three possibilities:

• always print help
• find .nvmrc and print that out, else print help
• be an alias to which node

The first seems consistent but valueless.

The second is consistent with nvm run, nvm exec, nvm use, nvm install, etc, and would only be different from the first when someone had made an .nvmrc file and thus expected that file to be parsed.

The third doesn't seem to add much value, since anywhere it would work, which node would also work.

Thoughts?

[ljharb]

I just tested this, and it seems to confirm with option 2 above. I'm going to merge this - thanks for your persistence and contribution!