Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

System-install defaults to RVM ruby, not system ruby #1110

Closed
mipearson opened this Issue · 3 comments

3 participants

mipearson Richo Healey Michal Papis
mipearson

On Ubuntu 10.04, system ruby is REE using Ubuntu packages from http://www.rubyenterpriseedition.com/download.html

Reproduction:

  • Install RVM system-wide using curl -L https://get.rvm.io | sudo bash -s stable
  • Install a Ruby using RVM as a regular user (in this case it was ruby-1.9.3-p194)
  • Log out, or re-boot the system
  • rvm info and ruby -v both show 1.9.3, not the system REE 1.8.7

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).

Richo Healey
Collaborator

I think potentially it's the heuristic for system ruby at fault, I don't recall seeing this behaviour before.

Richo Healey richo was assigned
Michal Papis
Collaborator

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.

Michal Papis mpapis closed this
mipearson

@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.

Michal Papis mpapis reopened this
Michal Papis mpapis closed this in 7a5f3b2
Michal Papis mpapis was assigned
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.