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