A Gem's Gemfile.lock should NOT be in source control. #14
Comments
A gem should not commit Gemfile.lock. In this case, a stale dependency on json 1.7.5 was breaking my `bundle install` on ruby 2.2.1, due to the version incompatibility. For more information on this, please see: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/ radar/guides#14 TenjinInc/dirt-core#1
|
I don't understand his reason. What if my gem depends on say Rails 3 and is not compatible with Rails 4? |
|
Then you should specify a version string for Rails 3 in your Gemfile, while still leaving Gemfile.lock ignored by git. Gemfile.lock is meant to be a full version lock for all dependencies specifically for deploying software. If you depend on certain version ranges of a gem to ensure compatibility, that belongs in Gemfile, not Gemfile.lock. |
|
More specifically, for gems, version constraints belong in the gemspec. |
|
More background on the rationale: Since the gem command only respects the dependency version constraints named in the gemspec, not Gemfile.lock, the presence of a Gemfile.lock is more likely to keep gem maintainers unaware of incompatibility with newer versions of dependencies that gem users will install but maintainers will not. Also, I'm commenting here because this issues shows up in Google search results. I understand that this issue and the gem development guide are several years old, and that although the gem-development directory contains a Gemfile.lock, the actual guide only explicitly suggests tracking Gemfile.lock when using the gem (in an app). |
|
I would gladly accept a patch here that improved the wording around this section, advocating for |
Further explanation from Bundler's author: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/ Fixes radar#14 Closes radar#23
Not needed in source control. We want to use the GitHub pages gem. See radar/guides#14
* Update .gitignore Adding Gemfile.lock to the list of files to ignore. The lock file is not needed on GitHub, and it gets generated when you run bundle jekyll server/build locally. Removing it ensures that we have the same dependencies that GitHub uses. * Delete Gemfile.lock Not needed in source control. We want to use the GitHub pages gem. See radar/guides#14
A gem should not commit Gemfile.lock. In this case, a stale dependency on json 1.7.5 was breaking my `bundle install` on ruby 2.2.1, due to the version incompatibility. For more information on this, please see: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/ radar/guides#14 TenjinInc/dirt-core#1
Via running `bundle update` and committing results. Some would advise not having Gemfile.lock checked into repo for gem source in the first place. Eg https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/ radar/guides#14 But if you are going to have it checked in, it's probably good to periodically update it so dev and test environments are against latest dependency releases that meet requirements.
The Gem Development guide says that the
Gemfile.lockfile "should always be checked into version control." However, this is NOT true for Gems. For Applications, like your Rails apps, Sinatra apps, etc., it is true. The same does not go for Gems.For clarification, please see Yehuda's guidance on the roles of
.gemspec,Gemfile, andGemfile.lockfiles: Clarifying the roles of .gemspec and GemfileThe text was updated successfully, but these errors were encountered: