When aliasing default, the "bin" and "share/man" directory are symlinked... #173

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
5 participants

jalaziz commented Nov 26, 2012

... to the NVM_DIR

This allows you to easily reference the path to global binaries (/home/user/.nvm/bin) in other scripts and tools. This also changes the binary download path to ~/.nvm/temp.

@jalaziz jalaziz When aliasing default, the "bin" and "share/man" directory are symlin…
…ked to the NVM_DIR

This allows you to easily reference the path to global binaries (/home/user/.nvm/bin) in other scripts and tools. This also changes the binary download path to ~/.nvm/temp.
ff99a2a

Linking binaries to a static location is a must, IMO.

Contributor

Marsup commented Mar 16, 2013

Why would you have to ? It's the job of nvm to point you to the right direction. What real use case does it solve that's impossible currently ?

jalaziz commented Mar 16, 2013

When scripting through python or ruby, it's much easier to simply run a command directly using a static path than to invoke a shell with the correct environment. It's not impossible, but static paths sure make scripting easier and more portable.

Contributor

Marsup commented Mar 16, 2013

You can't know where people will put their node binary, if they use nvm or nave or pure node. I don't understand how it is more portable if I have to go through a configuration file to tell what the system/shell already knows.

jalaziz commented Mar 16, 2013

Why would you have to go through a configuration file? It's very easy to test whether a path exists, and I doubt very many people move their nvm installation to something other than .nvm. As for portability, I'm not necessarily talking about other users, I'm talking about multiple environments (local vs servers) under your control.

I forgot the exact use case I had for this (as it was 4 months ago), but I do remember I was invoking binaries through a python script.

Again, it's not necessarily impossible to simply load nvm, but I like to simply refer to a static path than have to worry about loading the correct shell and paths. RVM has an .rvm/bin path where it stores wrappers, which is a much more sophisticated version of what I'm trying to accomplish. However, it also stores shortcuts to the default ruby, gem, bundle, etc.

I personally find this be something that should be standard and it simplifies my life. At least one other person seems to agree. You're certainly allowed to disagree.

chakrit commented Mar 16, 2013

No the system/shell do not always know. For example, if you install NVM to a "developer" user but your application actually runs as "app-user", the "app-user"will not have NVM command available (obviously) and in most cases, it will not be able to source NVM into its shell directly (chroot jail / home dir access permission / $PATH/$HOME complications breaking the nvm.sh script etc. etc.).

So the next best alternative is to hard-code the node binary path into the app startup/deployment script or symlink into /usr/local/bin/ but this defeats the purpose of having NVM on your server in the first place -- being able to change and experiment with the "default" node version without changing any node-related scripts/configuration/symlinks.

This does not have to be the case if nvm actually have a definitive place where the default node binary is maintained. Then we can all use this static path to get the default node version without hardcoding the actual node version number into any script or symlink. i.e. /home/developer/.nvm/v0.8.22/bin/node [fixed as 0.8.22] vs. /home/developer/.nvm/bin/node [whatever version nvm last defaulted to]

I have encountered this several times when deploying node with nvm and have resorted to creating a usr/local/bin/node and /usr/local/bin/npm symlink to whatever version I have installed with nvm but as I said before, this defeats the purpose of having nvm there and requires me to update these symlinks every time I want to update the node binary to a new patch version.

Also, just for comparative reference, rbenv does this by replacing the main ruby binary with a script (also placed at a static path) that scans the environment and picks the right version automatically which solves this problem in a very nice way.

Version managers should make the binaries (or symlinks) accessible from a sane predictable location. Otherwise if any other external program needs to also know the version number to access the installed binaries, then I think there is definitely room for improvement there.

Contributor

Marsup commented Mar 16, 2013

Having a static path won't save you if "app-user" doesn't have access to your nvm directory anyway.

I think that node should be accessible from anywhere so a symlink to the default into one of the $PATH folder should be good. A hardcoded path into your scripts doesn't seem very clean. Where that link is should be left to the user. Maybe a command to help do that symlink would be nice though.

chakrit commented Mar 16, 2013

I think that node should be accessible from anywhere so a symlink to the default into one of the $PATH folder should be good. snip Maybe a command to help do that symlink would be nice though.

Agree, yeah that'd work as well.

My use case is pretty simple.
I use WebStorm as my IDE. WS has a setting for node path and I can't use environment variables in that path. So, as it stands right now, I would have to go and change node path to point to a particular version of node in every Run/Debug configuration in WS every time I switch between versions (and I have about 20 of those configurations at the moment). So it's just not practical to do it this way. Having nvm link the current version somewhere like ~/.nmv/bin/node would solve this.

@ghost

ghost commented Mar 16, 2013

I have the same use case as diversario. I ended up doing a pull request for a simple symbolic link to the current node version without seeing this request first:

#208

Either way, this is definitely needed asap.

chakrit commented Apr 1, 2013

Had to setup another node machine today and figured I can get nvm's default alias pretty easily by cat-ing the default file:

For example:

$ "/var/nvm/$(cat /var/nvm/alias/default)/bin/node" --version
v0.8.22

This sort of fixes this issue for me.

Posting here in case anyone else needs a simple solution for this.

Collaborator

ljharb commented Aug 7, 2014

We now have a current symlink, as well as nvm exec and nvm run, so I think this can be closed.

ljharb closed this Aug 7, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment