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

Update "nvm use" to also alter npm's "prefix" configuration value #663

Closed
wants to merge 1 commit into from
Closed

Conversation

elrasguno
Copy link

My project makes use of libraries that have what I like to call "special C bits" -- specifically "zmq" and "mongodb" -- which require compilation per version of node. In order to test one module that depends on zmq with multiple node / iojs versions, you'd have to either recompile the zmq library each time you ran the "nvm use" command, OR write a script to install certain libraries (like zmq) in separate, version specific global npm prefix directories.

The changes in this pull request would simply run the "npm config set prefix" command to change npm's "prefix" variable to be something other than the default of /usr or /usr/local

If it's the case that this is too special casey, please let me know, and consider adding a flag to the "nvm use" command. I'd much rather work from the mainline than my fork.

Also, I did read the CONTRIBUTING page, but I'm not 100% sure on the most appropriate way to test it. What's required at a minimum is that

  1. At least two node / iojs versions are installed, including "system"
  2. Switching between them updates the value returned by the npm config get prefix command.

Is it OK i.e best practice to install two arbitrary versions and switch between them? Should I go the extra mile to install versions that aren't installed and remove them afterwards?

Thanks in advance.

…ration value

My project makes use of libraries that have what I like to call "special C bits" -- specifically "[zmq](https://github.com/JustinTulloss/zeromq.node)" and "[mongodb](https://github.com/mongodb/node-mongodb-native)" -- which require compilation per version of node. In order to test one module that depends on _zmq_ with multiple node / iojs versions, you'd have to either recompile the _zmq_ library each time you ran the "nvm use" command, OR write a script to install certain libraries (like _zmq_) in separate, version specific global npm prefix directories.

The changes in this pull request would simply run the "npm config set prefix" command to change npm's "prefix" variable to be something other than the default of _/usr_ or _/usr/local_

If it's the case that this is too special casey, please let me know, and consider adding a flag to the "nvm use" command. I'd much rather work from the mainline than my fork.
@ljharb
Copy link
Member

ljharb commented Feb 16, 2015

Thanks so much for contributing!

nvm is definitely used to switch between many versions at once (I have 5-6 installed at any one time). The primary use case of nvm is to have two shells side-by-side running different versions simultaneously.

For this reason, however, setting npm's prefix won't work - because it would conflict (or be a race condition) across multiple shells. (fwiw, npm root -g may be a helpful command here as well)

I would argue that a binary module should be recompiled against every single version you test against. Shared global modules across multiple versions of node/iojs are not a great idea.

@ljharb
Copy link
Member

ljharb commented Feb 16, 2015

Also, due to #606, I'm considering making nvm force unset npm's global prefix specifically to avoid that issue, so this would conflict with that too.

@ljharb ljharb closed this Feb 16, 2015
@elrasguno
Copy link
Author

@ljharb Thanks for responding so quickly!

I also agree that binary modules need to be recompiled for each separate version. In my particular case, I'm just looking to save time when switching between 0.10, 0.12, and iojs instead of needing to recompile each time I run nvm use.

Lastly, I learned quite a bit of bash by just looking at nvm.sh, so thanks for that as well.

@ljharb
Copy link
Member

ljharb commented Feb 17, 2015

@elrasguno all three of those have different compiler requirements (which is why so many binary modules have broken with the release of 0.12 and io.js) so I think you'd still want to recompile.

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

Successfully merging this pull request may close these issues.

2 participants