How does bundler know whether Gemfile has changed?

Rails
1

I am trying to understand how bundler works. Looking at the manual [1]
it says
“If a Gemfile.lock does exist, and you have not updated your
Gemfile(5), bundler will fetch all remote sources, but use the
dependencies specified in the Gemfile.lock instead of resolving
dependencies.”
The question is how does it know whether Gemfile has been updated? I
expected to find something in Gemfile.lock but can’t see it.

Colin

[1] Gem Bundler – Manage your Ruby gems

2

On Dec 17, 4:50pm, Colin L. [email protected] wrote:

I am trying to understand how bundler works. Looking at the manual [1] it says
“If a Gemfile.lock does exist, and you have not updated your
Gemfile(5), bundler will fetch all remote sources, but use the
dependencies specified in the Gemfile.lock instead of resolving
dependencies.”
The question is how does it know whether Gemfile has been updated? I
expected to find something in Gemfile.lock but can’t see it.

Does it use the list of dependencies at the bottom of gemfile.lock?

Fred

3

On 17 December 2011 17:41, Frederick C. [email protected]
wrote:

Does it use the list of dependencies at the bottom of gemfile.lock?

I don’t there is enough information there. Looking at the section
there on Conservative Updating it would appear that it has to know the
previous version specification for every gem specified, in order to
know whether it has changed. Thinking about it further I don’t
think the information in the link is fully correct. When it talks
about whether Gemfile has changed, I think what it means is that it
looks at the spec in Gemfile for each gem and compares it with the
spec in gemfile.lock, if they are incompatible then that is what it
means by “changed”. So if for example one were to change the spec of
a gem from > 2.0.0 to >1.0.0 that would not actually trigger any
action, even though a change had been made, because the lockfile was
still compatible with the Gemfile.

Colin

4

Maybe it’s something as dumb as the difference in filemtime between
Gemfile and Gemfile.lock?

Walter

5

On 17 December 2011 17:51, Walter Lee D. [email protected] wrote:

Maybe it’s something as dumb as the difference in filemtime between Gemfile and
Gemfile.lock?

I thought that initially, but as I noted in my response to Fred that
is not sufficient as it would appear that it needs to remember the
version spec for each gem. See my reply to Fred for my current
thoughts.

Colin

6

On Dec 17, 2011, at 3:15 PM, Colin L. wrote:

On 17 December 2011 17:51, Walter Lee D. [email protected] wrote:

Maybe it’s something as dumb as the difference in filemtime between Gemfile and
Gemfile.lock?

I thought that initially, but as I noted in my response to Fred that
is not sufficient as it would appear that it needs to remember the
version spec for each gem. See my reply to Fred for my current
thoughts.

As far as I know, here’s how it works (all supposition, BTW):

First bundle install, you get a new Gemfile.lock, which includes the
actual installed versions of all the gems. At this point the
Gemfile.lock is definitely newer (in filesystem age) than the Gemfile.
Now you update your Gemfile, and the next time you try to run, the
bundler notices that the Gemfile is newer than the Gemfile.lock. So it
bugs you to run bundle install. That replaces the Gemfile.lock with a
new copy, which at that time is now newer than the Gemfile, and the
circle is complete.

Walter

7

On 17 December 2011 21:15, Walter Lee D. [email protected] wrote:

As far as I know, here’s how it works (all supposition, BTW):

First bundle install, you get a new Gemfile.lock, which includes the actual
installed versions of all the gems. At this point the Gemfile.lock is definitely
newer (in filesystem age) than the Gemfile. Now you update your Gemfile, and the
next time you try to run, the bundler notices that the Gemfile is newer than the
Gemfile.lock. So it bugs you to run bundle install. That replaces the Gemfile.lock
with a new copy, which at that time is now newer than the Gemfile, and the circle
is complete.

I don’t think that explains how it implements the logic in the
Conservative Updating section of
http://gembundler.com/man/bundle-install.1.html
Suppose that in the example shown one changed the spec for
activemerchant from nothing to >=1.0.0 at the same time as updating
the spec for actionpack. Reading the description literally that
should allow it to update actionpack, but I don’t think that it will,
as, so far as I can see, it has no way of knowing that the spec for
activemerchant has changed.

Colin

8

On 17 December 2011 20:13, Colin L. [email protected] wrote:

expected to find something in Gemfile.lock but can’t see it.

Does it use the list of dependencies at the bottom of gemfile.lock?

I don’t there is enough information there.

On looking at this again Fred is exactly right, as usual. The section
marked DEPENDENCIES at the end of gemfile.lock is effectively the
contents of Gemfile itself, as far as version information goes.
Bundler can compare this section with the current Gemfile in order to
see what has changed. I think may brain must have been on walkabout
when I looked at this previously.

Colin