What is the difference between Gemfile and Gemfile.lock in Ruby on Rails

Question

I am a beginner to Ruby on Rails and I am using Rails 3.0.9.

What is the difference between Gemfile and Gemfile.lock in Rails?

Solution 1

The Gemfile is where you specify which gems you want to use, and lets you specify which versions.

The Gemfile.lock file is where Bundler records the exact versions that were installed. This way, when the same library/project is loaded on another machine, running bundle install will look at the Gemfile.lock and install the exact same versions, rather than just using the Gemfile and installing the most recent versions. (Running different versions on different machines could lead to broken tests, etc.) You shouldn't ever have to directly edit the lock file.

Check out Bundler's Purpose and Rationale, specifically the Checking Your Code into Version Control section.

Solution 2

Usually we write dependencies in Gemfile as:

gem "nokogiri", "~> 1.4.4"
gem 'bcrypt-ruby', '~> 3.0.0'
gem 'uglifier', '>= 1.2.3'
..

Here you basically say: "I want nokogiri as long as it’s greater than version 1.4.4", etc. Now suppose that I have set up my Gemfile 8 months ago and I successful setup my app with this requirement. 8 months ago nokogiri version was 1.4.4. My rails apps was running perfectly without any problems with this version.

Now think I'm trying to build with the same Gemfile. But if we look at nokogiri versions we see that the current stable version has changed to 1.4.9. That means if we try to build, bundler will install version 1.4.9 of nokogiri (suppose we don't have Gemfile.lock).

What does it mean ?

As you see if you don't have any Gemfile.lock and run:

bundle install

then the currently used gems can be different at any time. Your app used the version 1.4.4 and it works 8 months ago without any problems, but if you try to build it now you get the version 1.4.9. Maybe it's broken with the latest version of nokogiri, the awesome feature you used with 1.4.4 is not more available, etc..

To prevent this kind of problem Gemfile.lock is used. In Gemfile.lock only the exact versions are written and thus only these will be installed. That means if you distribute your app with a Gemfile.lock, every machine will have the same gems installed and most important they all get the same version. This will give you a stable and common deployment stack.

How is Gemfile.lock created?

It is automatically created with the first:

bundle install

command. After that everytime you run bundle install, bundle will first look up Gemfile.lock and install the gems specified there. It's an habit to distribute this file among your projects to provide consistently and stability.

How to update Gemfile.lock?

If you're happy with the the latest version of your apps than you can update Gemfile.lock. Just reflect your changes to Gemfile. That means change the dependencies to the new exact versions in Gemfile. After that run:

bundle install

This will update you Gemfile.lock with your newest version of apps.

Solution 3

The Gemfile.lock

When you run bundle install, Bundler will persist the full names and versions of all gems that you used (including dependencies of the gems specified in the Gemfile(5)) into a file called Gemfile.lock.

Bundler uses this file in all subsequent calls to bundle install, which guarantees that you always use the same exact code, even as your application moves across machines.

Because of the way dependency resolution works, even a seemingly small change (for instance, an update to a point-release of a dependency of a gem in your Gemfile(5)) can result in radically different gems being needed to satisfy all dependencies.

As a result, you SHOULD check your Gemfile.lock into version control. If you do not, every machine that checks out your repository (including your production server) will resolve all dependencies again, which will result in different versions of third-party code being used if any of the gems in the Gemfile(5) or any of their dependencies have been updated.

Comments

[michael]

A very nice, clear description (I up-voted); but one nitpick, however: nokogiri ~> 1.4.4 wouldn't allow 1.5.3 to be installed; max allowed would be 1.4.x where x>=4 (for nokogiri that would be 1.4.7). The ~> operator means just the last digit in the used gem can be "greater than" the given version. E.g., foo ~> a.b.c.d means any version of foo is fine as long as it's still a.b.c.{something} where {something} >= d. See also related question

[Jonny]

What's confusing me is that you are already specifying specific version(s) by using gem "nokogiri", "~> 1.4.4" in the gemfile. Why couldn't the bundler just use that version? Is it because it's designed to intentionally install the latest versions of the gem by default?

[Matthew Flaschen]

@Jonny, see michael_n's comment. ~> 1.4.4 does not specify an exact version.

[Jonny]

@MatthewFlaschen Ah, right. I noticed a tilde is used in the ~>. How narrow is the scope of the this version specification (i.e. ~> 1.4.4) and would I use -> for an exact version if I needed to?

[Matthew Flaschen]

@Jonny, ~> 1.4.4 is equivalent to >= 1.4.4 and < 1.5. See bundler.io/v1.5/gemfile.html . For an exact version, just use gem 'foo', '1.4.4'.

[Guillermo Grau]

That's how it should work -- but apparently the Gemfile.lock includes 'open' versions in some cases (e.g. rails (4.0.0) requires bundler (>= 1.3.0, < 2.0)), which causes problems. Any idea how to avoid those 'open' dependencies?

[Janikan]

@michael_n - Nice catch. I updated the answer to use 1.4.9 instead of 1.5.3 to accurately reflect the behavior of the ~> operator.

[Jwan622]

Why don't we commit the gemfile.lock with a gem? What's so bad about it? Say my gem depends on Rails 3... shouldn't I specify this as a dependency in my Gemfile and therefore Gemfile.lock?

[JMess]

Great answer but please clarify "update Gemfile.lock?": Is this section saying that bundle install will check the Gemfile even if there is a Gemfile.lock and enforce new restrictions upon Gemfile.lock?