Should I check in `.ruby-gemset` and/or `.ruby-version`?

Question

I've just updated RVM, and in place of the old .rvmrc, it auto-created .ruby-gemset and .ruby-version.

I've always had .rvmrc files with contents like rvm use --create default@project_name. However, .ruby-version contains the specific Ruby version I'm running rather than default. I'm hesitant to check this in.

Also, I heard someone say on a podcast that one shouldn't check in .ruby-gemset because others may have their own preferences about how to name gemsets.

When should or shouldn't I check in .ruby-gemset and/or .ruby-version?

Specifically:

• What are some of the tradeoffs?
• How does the type of project affect the decision (for example, applications vs gems)?
• If they should be checked in, how does the type of project affect what should go in these files?

Citations from from the creators of tools like rvm, rbenv, etc would be appreciated in an answer.

Answer 1

For standard projects

Check in .ruby-version if your project depends on a ruby like ruby-2.0.0. Check in .ruby-gemset only if your team agreed on it. Add .rvmrc to .gitignore so anyone can override .ruby-* files settings with .rvmrc.

For gems

Check in .ruby-version with ruby-1.8.7 only if your project still targets ruby 1.8.7, otherwise check it in only if your gem requires it. Do not check in .ruby-gemset.

Answer 2

Checking in .rvmrc, .ruby-version or .ruby-gemset?

FOR:

• Your project has different branches (say a RubyGems project supporting Ruby 1.8, 1.9 and 2.0 versions). Its better to check in this file, so that your developers don't have to keep on editing these files when they switch branches. The same doesn't apply for an application though, where you'll mostly be working on only one Ruby version.

• Same case as above, but say you are running a CI server (say TeamCity/Jenkins/...) which automatically just runs rake spec for every check-in. You don't want to create separate build pipelines for each branch, just for the sake of having a separate rvm use ... for each branch. You just want the Ruby version selected automatically depending on the branch

• You have tight control over the environment and all the developers. You either don't need or dictate that they use the same ruby and gemset

• You are using Phusion Passenger or Capistrano, which automatically read .rvmrc files and chooses the right ruby for deployment/hosting

Also refer RVM Best Practices

AGAINST:

• You can compile your own Ruby in RVM, with some experimental patches, and give it a custom name.

  e.g. rvm install 1.9.3 --patch railsexpress,falcon --name ruby-1.9.3-perf

  In the above example, I've installed Ruby 1.9.3 with some great speed up patches (btw they are awesome), but rather than calling it 1.9.3, I'm calling it my own name. I would say rvm use ruby-1.9.3-perf whenever I need this. In this case, if the project has its own .ruby-version, then it messes up my environment. In my project, these patches are standard and we actively recommend those. But how developers name the resultant compiled Ruby is up to them

• Similarly, people use different gemsets. Some don't use gemsets at all. Some share the same gemset with different (but similar) ruby projects. Given this, again a single .ruby-gemset also doesn't work for everybody

• Your project has an obscure ruby version which just says 1.9.3. Your developers first installed the latest Ruby 1.9.3-p329. But they later just update RVM/Rbenv (since they're working on other projects). Their .rvmrc or .ruby-version just breaks, since the latest version of Ruby registered in RVM/Rbenv just changed from ruby-1.9.3-p329 to .ruby-1.9.3-p362, and it will say ruby-1.9.3-p362 not installed. This scenario tends to happen often.

As long as you specify a proper full name for your Ruby version (including patch level), you should be OK. Let's say your project's .ruby-version says ruby-1.9.3-p329. Its easy to compile your own Ruby with all these patches, and still just custom name it ruby-1.9.3-329 just so that the config files will pick up this ruby instead of the standard ruby.

Answer 3

I would include .ruby-version - you and anyone else working on the project, along with your servers, should be using the same version of Ruby.

.ruby-gemset.... up to you, I think.