A Gem's Gemfile.lock should NOT be in source control. #14

Closed
stevenharman opened this Issue Jun 23, 2011 · 5 comments

Comments

Projects
None yet
5 participants
@stevenharman

The Gem Development guide says that the Gemfile.lock file "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, and Gemfile.lock files: Clarifying the roles of .gemspec and Gemfile

ms-ati added a commit to ms-ati/Values that referenced this issue Apr 6, 2015

Remove Gemfile.lock
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

@ms-ati ms-ati referenced this issue in tcrayford/Values Apr 6, 2015

Merged

Remove Gemfile.lock #22

@summera summera referenced this issue in estately/rets May 24, 2015

Merged

Remove gemfile lock #112

@Jwan622

This comment has been minimized.

Show comment Hide comment
@Jwan622

Jwan622 Aug 4, 2016

I don't understand his reason. What if my gem depends on say Rails 3 and is not compatible with Rails 4?

Jwan622 commented Aug 4, 2016

I don't understand his reason. What if my gem depends on say Rails 3 and is not compatible with Rails 4?

@nickmccurdy

This comment has been minimized.

Show comment Hide comment
@nickmccurdy

nickmccurdy Sep 5, 2016

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.

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.

radar pushed a commit that referenced this issue Jun 30, 2017

radar pushed a commit that referenced this issue Jun 30, 2017

Fix some broken links
Closes #4 - Remove link for modern day ruby warrior
Closes #7 - Fix dead internal link on security
Closes #9 - Remove modern day ruby warrior from resources
Closes #14 - Fix link to rubygems mirror repo
Closes #5 - Fix broken links from rubyforge on make your own gem page
@nilbus

This comment has been minimized.

Show comment Hide comment
@nilbus

nilbus Sep 12, 2017

Contributor

More specifically, for gems, version constraints belong in the gemspec.

Contributor

nilbus commented Sep 12, 2017

More specifically, for gems, version constraints belong in the gemspec.

@nilbus

This comment has been minimized.

Show comment Hide comment
@nilbus

nilbus Sep 12, 2017

Contributor

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).

Contributor

nilbus commented Sep 12, 2017

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).

@radar

This comment has been minimized.

Show comment Hide comment
@radar

radar Sep 14, 2017

Owner

I would gladly accept a patch here that improved the wording around this section, advocating for Gemfile.lock to not be committed to version control. @nilbus: is that something that you'd want to do?

Owner

radar commented Sep 14, 2017

I would gladly accept a patch here that improved the wording around this section, advocating for Gemfile.lock to not be committed to version control. @nilbus: is that something that you'd want to do?

nilbus added a commit to nilbus/guides that referenced this issue Sep 14, 2017

@radar radar closed this in #74 Sep 22, 2017

d45 added a commit to tableau/extensions-api that referenced this issue Apr 17, 2018

Delete Gemfile.lock
Not needed in source control. We want to use the GitHub pages gem.  See radar/guides#14

d45 added a commit to tableau/extensions-api that referenced this issue Apr 17, 2018

Update .gitignore (#110)
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment