[LRUG] Gemfile.lock for gems - to check in or not to check in, that is the question

[Gareth Adams]

I don’t want to repeat any opinions, because what I agree with has already
been said (basically I agree with Stephen)

But I think this thread has got a bit confused by different
interpretations. The original question only relates to people
*developing gems*.

The recommendation for applications has *ALWAYS* been that you check in
Gemfile.lock, that’s called out in Yehuda's blog post and I don’t think
anyone disagrees with it. If you want multiple people to be working with
the same set of gems, you check in Gemfile.lock. (See also Docker, but
that’s a lot of overhead if you only need to manage gems)

It’s worth remembering that Bundler was at version 1.0.7 (3 months after
1.0.0) when the source blog post was written. Yehuda’s point of view was
explained in more detail here:

> I tend not to, so I can avoid getting surprised by bugs during updates of
> dependencies with ~>. In other words, I want to see what will happen if
people
> install the gem with `gem install` (or fresh in a bundle), which is
exactly
> the *opposite* of what I want in an application.
-
https://groups.google.com/forum/#!msg/ruby-bundler/ldJjA8ivqFs/OYXruxbgbwYJ

Relying on other people’s installs to catch bugs due to version changes is
pretty scrappy IMO and 7 years later I think that belongs in a build system
or some other checker. I'd check in the file myself.


On Wed, May 10, 2017 at 5:21 PM Talk21 <jason.hooper at talk21.com> wrote:

> I would follow the new advice. We are running a Ruby Padrino application
> that is now more than three years old. By committing the Gemfile.lock we
> have been able to keep all our remote servers and developer environments
> the same. We then can control upgrades to either the whole stack or single
> gems by bundling and then updating the Gemfile.lock and recommitting.
>
> Regards,
>
> Jason Hooper
>
> On 10 May 2017, at 11:08, Asfand Qazi <ayqazi at gmail.com> wrote:
>
> Hello,
>
> I have a question regarding Bundler, developing gems, and Gemfile.lock .
> It is a question I thought I had the answer to, but apparently not.
>
> I USED to believe that you do not check in Gemfile.lock, so as to allow
> situations during development to occur where your gem is used with a
> version of a dependency that you did not expect, therefore allowing
> possibly breaking interface changes to dependencies to be made apparent.
> This is what Mr. Katz says here, in 2010:
> http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
> .
>
> However, checking the latest bundler docs, here we read something
> different: http://bundler.io/v1.14/guides/creating_gem.html
>
> "By running bundle install, Bundler will generate the extremely important
> Gemfile.lock file. This file is responsible for ensuring that every system
> this library is developed on has the exact same gems so it should always be
> checked into version control. For more information on this file read “THE
> GEMFILE.LOCK” section of the bundle install manpage."
>
> Que?
>
> What do y'all think? Follow the old advice, or the new advice?
>
> Thanks
>
> Regards,
>     Asfand Qazi
>     The DevOps Doctors
>
>     E: asfand at thedevopsdoctors.com
>     W: https://www.thedevopsdoctors.com/
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20170510/e9dae6f8/attachment.html>