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

Najaf Ali ali at happybearsoftware.com
Wed May 10 05:01:10 PDT 2017


> 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 atHappy Bear SoftwarePhone: 07590 073 977Skype: alinajaf85
Timezone: London, UTC + 1LinkedIn |Twitter |Medium |GitHub

I run a technical consultancy specialising in Ruby on Rails. Have a look atthis
one-page info sheet 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  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/c3baf705/attachment.html>


More information about the Chat mailing list