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

Wed May 10 04:06:44 PDT 2017

Thank you all for the input. I'm going to continue following the 'check it
in for apps, do not check it in for gems' advice. I might even ping the
documentation owners to tell them to update their docs.

Regards,
     Asfand

On 10 May 2017 at 11:38, Duncan Stuart <dgmstuart at gmail.com> wrote:

> That documentation is indeed confusing. I would always always always
> commit the Gemfile.lock for an application, but ignore it for a gem, but
> that documentation does indeed seem to say "commit your lockfile for gem
> development as well"
>
> I guess it doesn't matter a huge amount: as I understand it, the
> Gemfile.lock has no effect on an application that your gem is included in,
> and is only used for developing and testing the gem in isolation. I can see
> how it would make sense to lock your *development *dependencies (e.g.
> RSpec) to specific versions.
>
> On 10 May 2017 at 11:25, Stuart Harrison <pezholio at gmail.com> wrote:
>
>> I think the `bundle gem` command adds the lockfile to `.gitignore` by
>> default.
>>
>>
>> On 10 May 2017 at 11:24:12, Sam Phillips (sam at samsworldofno.com) wrote:
>>
>> Yes, always check it in. Once the dependency tree is resolved, you want
>> everyone using the same gems until it's actively changed.
>>
>> On 10 May 2017 at 11:22, Garry Shutler <garry at robustsoftware.co.uk>
>> wrote:
>>
>>> +1 to what Kerry said. If you deploy the same commit of your website
>>> tomorrow, you don't want it bringing in different, potentially breaking,
>>> versions of gems.
>>>
>>> *Garry Shutler*
>>> @gshutler <http://twitter.com/gshutler>
>>> gshutler.com
>>>
>>> On 10 May 2017 at 11:12, Kerry Buckley <kerryjbuckley at gmail.com> wrote:
>>>
>>>> The advice I've always followed is that if you're building an
>>>> application you check it in (so you can guarantee that everyone's
>>>> developing/testing/running against the same set of dependencies), but if
>>>> you're building a library you don't, as you don't get to control what
>>>> versions users of your library are running (other than through the
>>>> dependency specifications in your gemspec).
>>>>
>>>> Kerry
>>>>
>>>> On Wed, May 10, 2017 at 11:08 AM, 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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/40034e4f/attachment-0002.html>