Q: I understand the value of locking my gems down
to specific versions, but why can't I just specify
for all my dependencies in the
Gemfile and forget about
A: Many of your gems will have their own
dependencies, and they are unlikely to specify
Moreover, it is probably unwise for gems to lock down all of *their*
dependencies so strictly. The
Gemfile.lock allows you to
specify the versions of the dependencies that your application needs in
Gemfile, while remembering all of the exact versions of
third-party code that your application used when it last worked correctly.
By specifying looser dependencies in your
nokogiri ~> 1.4.2), you gain the ability to run
bundle update nokogiri, and let bundler handle updating **only**
nokogiri and its dependencies to the latest version that still
~> 1.4.2 version requirement. This also allows you
to say "I want to use the current version of nokogiri" (
Gemfile) without having to look up the exact version number,
while still getting the benefits of ensuring that your application always runs with
exactly the same versions of all third-party code.
Q: I don't understand why I need bundler to manage my gems in this manner. Why can't I just get the gems I need and stick them in submodules, then put each of the submodules on the load path?
A: Unfortunately, that solution requires that you
manually resolve all of the dependencies in your application, including dependencies
of dependencies. And even once you do that successfully, you would need to redo that
work if you wanted to update a particular gem. For instance, if you wanted to update
rails gem, you would need to find all of the gems that depended on
dependencies of Rails (
tzinfo, etc.), and find new versions that satisfy the new versions of
Frankly, this is the sort of problem that computers are good at, and which you, a developer, should not need to spend time doing.
More concerningly, if you made a mistake in the manual dependency resolution
process, you would not get any feedback about conflicts between different dependencies,
resulting in subtle runtime errors. For instance, if you accidentally stuck the wrong
rack in a submodule, it would likely break at runtime, when
Rails or another dependency tried to rely on a method that was not present.
Bottom line: even though it might seem simpler at first glance, it is decidedly significantly more complex.
Q: I ran
bundle install --without production and
bundler is still downloading the gems in the
:production group. Why?
Gemfile.lock has to contain exact
versions of all dependencies in your
Gemfile, regardless of any options
you pass in. If it did not, deploying your application to production might change all
your dependencies, eliminating the benefit of Bundler. You could no longer be sure that
your application uses the same gems in production that you used to develop and test with.
Additionally, adding a dependency in production might result in an application that is
impossible to deploy.
For instance, imagine you have a production-only gem (let's call it
rack-debugging) that depends on
rack =1.1. If we did not evaluate
the production group when you ran
bundle install --without production, you
would deploy your application, only to receive an error that
rails (which depends on
actionpack, which depends
rack ~> 1.2.1).
Another example: imagine a simple Rack application that has
Gemfile. Again, imagine that you put
rack-debugging in the
:production group. If we did not evaluate the
:production group when
you installed via
bundle install --without production, your app would use
rack 1.2.1 in development, and you would learn, at deployment time, that
rack-debugging conflicts with the version of Rack that you tested with.
In contrast, by evaluating the gems in **all** groups when you call
regardless of the groups you actually want to use in that environment, we will discover the
rack-debugger requirement, and install
rack 1.1, which is also compatible
gem 'rack' requirement in your
In short, by always evaluating all of the dependencies in your Gemfile, regardless of the dependencies you intend to use in a particular environment, you avoid nasty surprises when switching to a different set of groups in a different environment. And because we just download (but do not install) the gems, you won't have to worry about the possibility of a difficult **installation** process for a gem that you only use in production (or in development).
Q: I have a C extension gem, such as
mysql, which requires
special flags in order to compile and install. How can I pass these flags into the installation
process for those gems?
A: First of all, this problem does not exist for the
gem, which is a drop-in replacement for the
mysql gem. In general, modern C extensions
properly discover the needed headers.
If you really need to pass flags to a C extension, you can use the
$ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
Bundler will store this configuration in
~/.bundle/config, and bundler will use
the configuration for any
bundle install performed by the same user. As a result, once
you specify the necessary build flags for a gem, you can successfully install that gem as many times
Q: I do not have an internet connection but I have installed the gem before. How do I get bundler to use my local gem cache and not connect to the gem server?
A: Use the --local flag with bundle install. The --local flag tells bundler to use the local gem cache instead of reaching out to the remote gem server.
$ bundle install --local
Q: When I bundle from RubyGems.org, it is really slow. Is there anything I can do to make it faster?
A: First, update to the latest version of Bundler by running `gem install bundler`. We have added many, many improvements that make installing gems faster over the years. If you have an extremely high-latency connection, you might also see an improvement by using the `--full-index` flag. This downloads gem information all at once, instead of making many small HTTP requests.
$ bundle install --full-index
Q: What happens if I put a `Gemfile` in my gem?
A: When someone installs your gem, the `Gemfile` and `Gemfile.lock` files are completely ignored, even if you include them inside the `.gem` file you upload to rubygems.org. The `Gemfile` inside your gem is only to make it easy for developers (like you) to install the dependencies needed to do development work on your gem. The `Gemfile` also provides an easy way to track and install development-only or test-only gems. Read about Gemfiles in gems from the Bundler in gems page and the How to create a gem with Bundler guide.
Q: Should I commit my `Gemfile.lock` when writing a gem?
A: Yes, you should commit it. The presence of a `Gemfile.lock` in a gem's repository ensures that a fresh checkout of the repository uses the exact same set of dependencies every time. We believe this makes repositories more friendly towards new and existing contributors. Ideally, anyone should be able to clone the repo, run `bundle install`, and have passing tests. If you don't check in your `Gemfile.lock`, new contributors can get different versions of your dependencies, and run into failing tests that they don't know how to fix.
Q: But I have read that gems should not check in the Gemfile.lock!
A: The main advantage of not checking in your Gemfile.lock is that new checkouts (including CI) will immediately have failing tests if one of your dependencies changes in a breaking way. Instead of forcing every fresh checkout (and possible new contributor) to encounter broken builds, the Bundler team recommends either using a tool like Dependabot to automatically create a PR and run the test suite any time your dependencies release new versions. If you don't want to use a dependency monitoring bot, we suggest creating an additional daily CI build that deletes the Gemfile.lock before running `bundle install`. That way you, and others monitoring your CI status, will be the first to know about any failures from dependency changes.