TL;DR : Bundler tracks your application’s code and the gems it needs to run, so that the application will always have the exact gems (and versions) that it needs to run. Add the Gemfile.lock generated by Bundler to version control. Bundler’s home is http://gembundler.com.
We know how to install and manage our rubies, and we know how to install and store our gems. The one thing left is how to manage them. The tool for that is Bundler.
It gives you the power to manage your gems per-project. For example Rails uses Bundler to manage the libraries used by an application. You can put your gem configurations under source control and that way all the developers will work in the same environment, with the same versions of the gems. If you remember my article about portable Vim, the idea for the VundleFile is influenced by Bundler’s Gemfiles.
Now is time to install Bundler:
gem install bundler
mkdir -p ~/development/ruby/project cd development/ruby/project mkdir lib mkdir spec
Your source code will be in ‘lib’, your specs will be in ‘spec’ (If you don’t know what is a spec, you will be very happy to find out here).
If we want Bundler to manage the gems for our application we can create a file called ‘Gemfile‘ or execute
which will generate it for us.
The Gemfile lists the gems used by our projects. A Gemfile contains one or more sources:
These sources point to the gem servers which will be used to download the gems for the project. If you ran ‘bundle init’, you already have the rubygems.org source.
If you have at least one source, you can add the gems needed by your project. You can:
- Depend on gems from the source servers, listing only their names.
- Depend on given gem versions or version ranges.
See http://docs.rubygems.org/read/chapter/16#page74 or more information. You should read about ‘~>’ if it is new for you.
gem 'rails', '4.0.0.rc1' gem 'rack', '>=1.0' gem 'thin', '~>1.1'
- Depend on a gems located in a Git repositories. You can specify revisions, tags and branches.
gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git'
- Depend on gems downloaded locally or written by you.
gem 'nokogiri', :path => 'gems/nokogiri'
You can specify the Ruby versions your project is compatible with:
And you can create gem groups. For example:
# These gems are in the :default group gem 'nokogiri' gem 'sinatra' gem 'wirble', :group => :development group :test do gem 'faker' gem 'rspec' end group :test, :development do gem 'capybara' gem 'rspec-rails' endgem 'cucumber', :group => [:cucumber, :test]
This way, for example, gems needed by the specs will be required only when you run Rspec, gems needed by the production will be required only on the production server, etc…
For more about Gemfiles – http://gembundler.com/v1.3/gemfile.html.
Now if you run:
All the gems listed in the Gemfile will be downloaded and will be available to your project. A special Gemfile.lock will be generated. This Gemfile.lock is very important. You must add it to version control! Be aware that Bundler downloads the gems listed in the Gemfile and their dependencies. By default they are downloaded in your current ruby installation folder’s ‘gems‘ sub-folder.
The Gemfile.lock contains the dependencies and the exact versions of the downloaded gems.
Next time you run the ‘bundle install‘ command this file will be used by Bundler to decide which versions should be downloaded.
Think about it… When you wrote your code, you listed rack as gem without specifying its version. The version of rack was 1.0 at the time, but now it is 2.3 (for example). The current version’s code is very different and your code is not compatible with it. But if you checkout your project somewhere and the Gemfile.lock is in it, Bundler will download rack version 1.0, because this is the version in the Gemfile.lock, the version that was the newest when you first run ‘bundle install‘.
If you wan to update the Gemfile.lock to include the newest versions, there is ‘bundle update‘ command. I’m not going to talk about it now, but do not update Gemfile.lock manually!
So this is Bundler, you and your collaborators will work with the same ruby version and the same gems and gem versions. This way the project is set-upped to work everywhere. When your friends checkout the project and run ‘bundle install‘, everything will be downloaded and configured.
I can continue talking about installing gems contained only in given group, or installing gems in your project’s path, but I think the post is long enough.
You can require your all the gems from your Gemfile or different groups using:
Bundler.require(:default, [:<group_name>, [<more_groups>]])
There is a Bundle.setup method too which adds your gems to the load paths and then you can require them manually. But more about that some rainy day.
- Bundler’s site – http://gembundler.com
- Bundle.setup vs Bundle.require, a topic I didn’t cover – http://anti-pattern.com/bundler-setup-vs-bundler-require
- About Bundle.install – http://gembundler.com/v1.3/man/bundle-install.1.html
- How to use Bundle.update – http://ilikestuffblog.com/2012/07/01/you-should-update-one-gem-at-a-time-with-bundler-heres-how