Last updated 7 January 2017
Learn tips and tricks for managing Rails and Ruby gems. Relieve your headaches when versions collide.
This is a guide for developers using the example apps from the Rails Apps repository. Others may find it helpful as well.
Before you install one of the Rails example apps, there are a few things you should know about managing the pieces of the Rails platform. Often, everything “just works,” but when it doesn’t, here’s what you need to review. Read on if you’d like to know how all the moving parts work together.
If you’re new to Rails, see What is Ruby on Rails?, the book Learn Ruby on Rails, and recommendations for a Rails tutorial.
See Installing Rails for detailed instructions and advice.
The example apps from the Rails Apps repository help you keep current with changing Rails and gem versions.
Each example provides a set of useful, popular Rails gems integrated into a working application. Each example is known to work and can serve as your personal “reference implementation”. Each is an open source project. Many developers use the apps, report problems as they arise, and propose solutions as GitHub issues.
These examples provide a working Rails app with a detailed tutorial that can be used to create a starter app. Each of these example apps can be created using the Rails Composer tool (“like the ‘rails new’ command on steroids”):
| Example Applications for Rails | Tutorial | Comments |
|---|---|---|
| Learn Rails | Learn Ruby on Rails | introduction to Rails for beginners |
| Rails and Bootstrap | Rails Bootstrap Tutorial | starter app for Rails and Bootstrap |
| Rails and Foundation | Rails Foundation Tutorial | starter app for Rails and Zurb Foundation |
| Mailing List with Active Job | Mailing List with Active Job Tutorial | background processing |
| OmniAuth and Rails | OmniAuth Tutorial | OmniAuth for authentication |
| Devise and Rails | Devise Tutorial | Devise for authentication |
| Role-Based Authorization | Role-Based Authorization Tutorial | Simple authorization |
| Pundit and Rails | Rails Pundit Tutorial | Pundit for authorization |
| Sign Up and Download | Sign Up and Download Tutorial | Devise with authorization to download a PDF file |
| Stripe Checkout | Stripe Checkout Tutorial | selling a product with Stripe Checkout |
Ruby is the programming language used for Rails projects.
What version of Ruby is installed on your machine? Check with:
$ ruby -v
Make sure it is the most recent version of Ruby.
You can check for the current recommended version of Ruby.
See instructions for Installing Rails to install a newer version of Ruby if necessary.
RubyGems is a package management framework for Ruby. A gem is a packaged Ruby application or library. You can read more about gems if you wish. Gems come from a wonderful pool of open source love but can be a headache to track and integrate.
The RubyGems package management system comes as part of a standard Ruby language installation.
What version of the RubyGems system is installed on your machine? Check with:
$ gem -v
Use gem update --system to upgrade the RubyGems system.
Rails itself is a gem, which means it can be installed and updated like any other gem.
What version of Rails is installed on your machine? Check with:
$ rails -v
You can check for the newest released Rails version.
See instructions for Installing Rails to install or update Rails. I recommend that you create a new gemset using rvm before installing a new version of Rails (rather than using gem update rails). With rvm, you can switch gemsets to run your application under an earlier version of Rails.
The Ruby Bundler manages an application’s gems. Bundler works by reading a Gemfile in an application’s root directory, downloading and unpacking specified versions of each required gem, resolving any dependencies among gems, and creating a Gemfile.lock file to force use of the specified gem versions.
Each of the example apps is provided with a gemfile that specifies a known working set of required gems.
After creating an example app, run bundle install to install all the necessary gems.
If you add a new gem to the gemfile, run bundle install again.
If you want to force an upgrade to all the gems that have newer versions, run bundle update. When you update a gem, bundler will not update a dependency of that gem if another gem still depends on it.
You will specify the gems you need in your application’s Gemfile. If you don’t specify a version, your application will use the newest gem version installed on your machine.
If you run bundle update, each gem will be updated to the newest available. You may benefit from the features (or the bug fixes) of the newest version. Or you may discover integration issues with other gems which cause failures. To avoid surprises and manage gem updates cautiously, you can specify gem versions in your Gemfile (described in the RubyGems manual).
In the gemfiles for the example apps, you’ll often see “optimistic version constraint” specified with the >= operator like this:
gem 'devise', '>= 1.3.4'
This means, “use any version of the Devise gem that is newer than version 1.3.4.” It will force an upgrade of the Devise gem to version 1.3.4 the first time you run bundle update and check and install newer versions each subsequent time you run bundle update. That’s a good scheme for keeping your gems up-to-date unless there is a known issue with a gem.
In the some gemfiles you may see “pessimistic version constraint” like this:
gem 'library', '~> 2.2'
which is shorthand for
gem 'library', '>= 2.2.0', '< 3.0'
which means use any gem version newer than 2.2.0 but don’t install 3.0 or anything newer.
We seldom specify pessimistic version constraint for gems in the example apps unless a gem developer recommends it.
See recommendations about using pessimistic version constraint in a blog post by Dan Croak titled Twiddle Wakka (yes, the ~> operator is variously known as the “twiddle wakka,” “tildemator,” or “spermy operator.”)
In the example apps, we use “absolute version constraint” to specify a known working version of a gem if we’ve seen reported problems with newer versions. Absolute version constraint looks like this:
gem 'library', '2.2'
I recommend installing rvm, the Ruby Version Manager. It’s essential if you must use multiple versions of Rails. And rvm makes it easy to switch sets of gems if you suspect a problem with incompatibilities among gems.
The rvm website explains how to install rvm.
See instructions for Installing Rails to install Rails and create a new gemset using rvm.
RVM recognizes .ruby-version and .ruby-gemset files in a directory and loads a specified gemset.
Here’s how to create .ruby-version and .ruby-gemset files if you’re using a gemset named “ruby-2.2.0@myapp”:
$ echo "ruby-2.4.0" > .ruby-version $ echo "myapp" > .ruby-gemset
Using .ruby-version and .ruby-gemset files means you’ll automatically be using the correct Rails and gem version when you run your application on your local machine. This works best if you create an rvm gemset specifically for your application.
Comments
Is this helpful? Your encouragement fuels the project. Please tweet or add a comment. Couldn't get something to work? For the example apps and tutorials, it's best to open an issue on GitHub so we can help you.
comments powered by Disqus