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

Wed May 10 08:47:38 PDT 2017

There is an argument that testing a gem against the latest versions of all dependencies is very important, and not checking in a Gemfile so your CI does this is an easy way of achieving that.

Whatever situation you're in I think waiting for other people to arbitrarily break your things at any time isn't a great way to live so I prefer to always check in the lock file so my apps and gems all have stable states to develop against.

Testing against other versions is something I'd rather do deliberately. As Ben was saying there are tools to help with this now and had they existed when the advice was published I suspect it might have been more nuanced.

Bestie.

> On 10 May 2017, at 15:43, Riccardo Tacconi <rtacconi at gmail.com> wrote:
> 
> +1
> 
> Yes, Asfand, I agree. The lockfile ensures that every developer has the same version of gems. Gems are a bit different, you put your dependencies in the Gemspec and when it will be used it will become part of a bigger (usually) code base where Bundler will have to resolve the dependency tree of your gem, other gems and your local project's Gemfile.
> 
> Instead of using bundler, developers should use docker-compose to run the app, gems will be already be installed for them, including compiling and packaging other dependencies.
> 
>> On 10 May 2017 at 12:06, Asfand Qazi <ayqazi at gmail.com> wrote:
>> 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
>>>>>> 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
>> 
>> 
>> _______________________________________________
>> 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
> 
> 
> 
> -- 
> Riccardo Tacconi
> 
> _______________________________________________
> 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/5b96c060/attachment-0002.html>