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

Wed May 10 05:56:59 PDT 2017

On 10 May 2017 at 13:50, Asfand Qazi <ayqazi at gmail.com> wrote:

> I do not think a Gemfile.lock has any effect on a gem when it is being
> used. I think the point of not checking in your Gemfile.lock is to force
> the gem to be run against different minor versions of dependencies while it
> is being developed; different developers will probably have slight
> variations of dependencies (or as much is allowed by your gemspec)
> installed, or you will at different times of your life, thus forcing the
> gem to be more resilient when it comes to dealing with varying dependency
> versions.
>
> To quote the above Yehuda Katz article:
>
> "... when doing gem development, you want to know immediately when some
> change in the overall ecosystem breaks your setup ... you do not want to
> hardcode your development to a very specific set of gems, only to find out
> later that a gem released after you ran bundle install, but compatible with
> your version range, doesn't work with your code".
>
> It's not a very reliable way of doing this, perhaps someone should create
> a tool that checks out every combination of every valid version of your
> gem's dependencies and runs your tests against each combination.
>

It's common for gem authors to use either
https://github.com/thoughtbot/appraisal to achieve this or a essentially
the same thing with different `Gemfile`s a la the `gemfile` stanza here:
https://github.com/roidrage/lograge/blob/master/.travis.yml

Cheers,
Ben

> Regards,
>      Asfand
>
> On 10 May 2017 at 13:01, Najaf Ali <ali at happybearsoftware.com> wrote:
>
>> *> 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 dependencies (e.g. RSpec) to specific
>> versions.development *
>>
>> Yep, this is the bit I was confused about as well i.e. even if you do
>> commit your Gemfile.lock when creating a gem, does it even do anything?
>>
>> Najaf Ali - Founder at Happy Bear Software
>> <https://links5.mixmaxusercontent.com/rSxCBSBNkaSyYEvDv/l/0hwoH3nHCguJwZ6ah?messageId=zThlHJEOJKfAaQYlX&rn=gIwV3bydEIzJXZzVFI5JWdSBibvRmbvxkI&re=icmcv5yZ1JHbuMHdzlGbARXYoNmI>
>> Phone: 07590 073 977 <07590%20073977>
>> Skype: alinajaf85
>> Timezone: London, UTC + 1
>> <https://links6.mixmaxusercontent.com/rSxCBSBNkaSyYEvDv/l/Zm84nAWnarmhOlHKl?messageId=zThlHJEOJKfAaQYlX&rn=gIwV3bydEIzJXZzVFI5JWdSBibvRmbvxkI&re=icmcv5yZ1JHbuMHdzlGbARXYoNmI>
>> LinkedIn
>> <https://links9.mixmaxusercontent.com/rSxCBSBNkaSyYEvDv/l/8R4Qlo498iH9T03xG?messageId=zThlHJEOJKfAaQYlX&rn=gIwV3bydEIzJXZzVFI5JWdSBibvRmbvxkI&re=icmcv5yZ1JHbuMHdzlGbARXYoNmI>
>>  | Twitter
>> <https://links8.mixmaxusercontent.com/rSxCBSBNkaSyYEvDv/l/42d191qOG0e9cuoem?messageId=zThlHJEOJKfAaQYlX&rn=gIwV3bydEIzJXZzVFI5JWdSBibvRmbvxkI&re=icmcv5yZ1JHbuMHdzlGbARXYoNmI>
>>  | Medium
>> <https://links10.mixmaxusercontent.com/rSxCBSBNkaSyYEvDv/l/S4rJO5LpCmp01J1oI?messageId=zThlHJEOJKfAaQYlX&rn=gIwV3bydEIzJXZzVFI5JWdSBibvRmbvxkI&re=icmcv5yZ1JHbuMHdzlGbARXYoNmI>
>>  | GitHub
>> <https://links7.mixmaxusercontent.com/rSxCBSBNkaSyYEvDv/l/69tqwmKY5R8Anqof6?messageId=zThlHJEOJKfAaQYlX&rn=gIwV3bydEIzJXZzVFI5JWdSBibvRmbvxkI&re=icmcv5yZ1JHbuMHdzlGbARXYoNmI>
>>
>> I run a technical consultancy specialising in Ruby on Rails. Have a look
>> at this one-page info sheet
>> <https://links3.mixmaxusercontent.com/rSxCBSBNkaSyYEvDv/l/s5jEI76TvZ9MHczlF?messageId=zThlHJEOJKfAaQYlX&rn=gIwV3bydEIzJXZzVFI5JWdSBibvRmbvxkI&re=icmcv5yZ1JHbuMHdzlGbARXYoNmI> for
>> a summary of the services we provide. We're always happy to meet people
>> building software, so if you think of anyone appropriate for us we would
>> appreciate being put in touch :-)
>>
>>
>>
>> On Wed, May 10, 2017 12:06 PM, 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 <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
>>>
>>>
>>>
>> _______________________________________________
>> 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/6ac97336/attachment-0002.html>