FYI <a href="https://github.com/radar/guides/pull/23">https://github.com/radar/guides/pull/23</a> from 5 years ago.<br><br>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. <br><br>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.<br><div class="gmail_quote"><div dir="ltr">On Wed, 10 May 2017 at 19:30, Mark Burns <<a href="mailto:markthedeveloper@gmail.com">markthedeveloper@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the confusion comes from library vs application.<br><br>Unfortunately/fortunately rubygems and bundler can be used for distributing library code AND standalone applications.<br><br>In this example, the foodie CLI is an application distributable and installable via rubygems. It is not intended to be used as a library.<br>So its dependencies should be locked down.<br> <br>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.<br><br><div class="gmail_quote"><div dir="ltr">On Wed, 10 May 2017 at 17:21, Talk21 <<a href="mailto:jason.hooper@talk21.com" target="_blank">jason.hooper@talk21.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br><div>
Regards,
</div><div><br class="m_954276655949114386m_-401494561549279047webkit-block-placeholder"></div><div>Jason Hooper</div></div></div><div style="word-wrap:break-word"><div>
<br><div><blockquote type="cite"><div>On 10 May 2017, at 11:08, Asfand Qazi <<a href="mailto:ayqazi@gmail.com" target="_blank">ayqazi@gmail.com</a>> wrote:</div><br class="m_954276655949114386m_-401494561549279047Apple-interchange-newline"><div><div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>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: <a href="http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/" target="_blank">http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/</a>.</div><div><br></div><div>However, checking the latest bundler docs, here we read something different: <a href="http://bundler.io/v1.14/guides/creating_gem.html" target="_blank">http://bundler.io/v1.14/guides/creating_gem.html</a></div><div><br></div><div>"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."</div><div><br></div><div>Que?</div><div><br></div><div>What do y'all think? Follow the old advice, or the new advice?</div><div><br></div><div>Thanks</div><div><br class="m_954276655949114386m_-401494561549279047gmail-Apple-interchange-newline">Regards,<br> Asfand Qazi<br> The DevOps Doctors<br><br> E: <a href="mailto:asfand@thedevopsdoctors.com" target="_blank">asfand@thedevopsdoctors.com</a><br> W: <a href="https://www.thedevopsdoctors.com/" target="_blank">https://www.thedevopsdoctors.com/</a><br>
</div></div>
_______________________________________________<br>Chat mailing list<br><a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div></blockquote></div>