How does bundler know whether Gemfile has changed?

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

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

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

Walter

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

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

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

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

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