GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
On Ubuntu 10.04, system ruby is REE using Ubuntu packages from http://www.rubyenterpriseedition.com/download.html
curl -L https://get.rvm.io | sudo bash -s stable
I can understand why this behaviour is convenient, but it is an unfortunate surprise when installing RVM on a production system, especially as for us it exposed itself when a system init script ran something (in this case Jenkins) and that then ran Ruby and couldn't find its gems.
If you do not believe this behaviour should be changed, I believe that a warning should be placed in the documentation (similar to the umask warning already there).
I think potentially it's the heuristic for system ruby at fault, I don't recall seeing this behaviour before.
this is because first installed ruby is made default, it can be avoided by running RVM in binary mode:
command rvm install 1.9.3
also you can remove the default with:
rvm alias delete default
finally you can add system ruby to RVM and make it default:
rvm use system
rvm mount $(which ruby) -n system-ree
rvm alias create default ext-system-ree
ext is prefix for existing rubies mounted into RVM.
@mipearson let me know if none of those tree is an option for you, or if there are any errors with them.
@mpapis This issue is that RVM does this by default, when there's no expectation that it should. It's a nod to convenience, which works well for a developer machine (where continual interactivity means you generally know which interpreter you're using) but can cause problems for a system-wide install.
It violates the principle of least surprise.
Our particular discovery of this issue was relatively benign: I rebooted our test machine, jenkins ran from init, and we had test failures as the 'default' ruby had changed. It took me a short while to figure out that I was seeing stacktraces from 1.9.1 directories, not 1.8, and then a bit of a wild goose chase as I tried to work out whether I had an errant script or .profile changing the interpreter for me. I was quite surprised to find that RVM was doing this for me.
I don't really want to think about what would have happened had we needed to restart our actual production machine.
As above, if you don't want to lose the convenience of this measure on a default install, I'd really appreciate it if you added a note about this behaviour to the documentation. You've done the same with the g+w umask, which is to be commended.
fix command rvm install first ruby, clean scripts/cli, update #1110