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

[Duncan Stuart]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20170510/b2d83001/attachment.html>