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

[Mark Burns]

FYI https://github.com/radar/guides/pull/23 from 5 years ago.

I think maybe more appropriate would be for someone to do a PR explaining
the use case of the Gemfile.lock for app development vs gems as libraries.

But I also think the whole article is confusing because most people write
gems to distribute libraries. So a library based guide would be more
fitting.
On Wed, 10 May 2017 at 19:30, Mark Burns <markthedeveloper at gmail.com> wrote:

> I think the confusion comes from library vs application.
>
> Unfortunately/fortunately rubygems and bundler can be used for
> distributing library code AND standalone applications.
>
> In this example, the foodie CLI is an application distributable and
> installable via rubygems. It is not intended to be used as a library.
> So its dependencies should be locked down.
>
> The normal use case for a gem is to NOT commit the Gemfile.lock as it
> should be more flexible when used as a library.
>
> On Wed, 10 May 2017 at 17:21, 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/b4dfb3d8/attachment-0003.html>