Remove gemfile lock

[summera]

I don't think we should commit Gemfile.lock. It can cause issues and is not recommended to commit to source control. For example, the issue mentioned in #110 is due to a stale dependency on json (~> 1.4) by rdoc which breaks bundle install with ruby 2.2 due to the version incompatibility. This issue can be fixed by simply adding Gemfile.lock to .gitignore and removing the file from source control.

For reference see:
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
radar/guides#14

TL;DR

_When developing a gem, use the gemspec method in your Gemfile to avoid duplication. In general, a gem's Gemfile should contain the Rubygems source and a single gemspec line. Do not check your Gemfile.lock into version control, since it enforces precision that does not exist in the gem command, which is used to install gems in practice. Even if the precision could be enforced, you wouldn't want it, since it would prevent people from using your library with versions of its dependencies that are different from the ones you used to develop the gem._

[wconrad]

The quoted advice is faulty. Not committing Gemfile.lock means that a developer wanting to work on this package has no assurance of using the same versions of dependencies as the maintainer did. For an example of why that's bad, see the comment at dbroeglin/nagios_check#4

As far as I can tell, Gemfile.lock is not used when someone installs a gem. Therefore, checking it in won't "prevent people from using your library with versions of its dependencies that are different from the ones you used to develop the gem." Unless those people are developing the gem; those developers should be using the same versions of dependencies.

[summera]

@wconrad I agree with you when it comes to App development; everything should be locked in and guaranteed. However, gems are focused on flexibility, reusability, and longevity.

The point you are making is actually a reason to NOT check the Gemfile.lock into source control and is backing up the quoted advice of Yehuda Katz above. That is, Gemfile.lock in gem source countrol does not lock users of the gem, when running gem install, into specific versions, as you have stated. This is because one would not want to prevent gem users from using different dependency versions with your library. You want to give users flexibility and want to provide a range of compatible dependency versions. This is what the dependency part of .gemspec is for.

Therefore, having the Gemfile.lock in source control can obscure issues for developers of the gem because gems are ultimately deployed with the gem command. You want to know immediately when some change in the overall ecosystem breaks your setup so that it can be fixed.

This is also why popular, well-known gems such as rspec, kaminari, HAML, Carrierwave etc., all with many contributors (Carrierwave has 244 contributors), do not commit their Gemfile.lock to source control and have it listed in their .gitignore.

In my opinion, the nagios_check PR you referenced should be fixed by fixing the dependency in the .gemspec. Do you mind providing an example of an issue or a PR submitted by an author other than yourself? Preferably one that has been merged into master.

[wconrad]

Not having Gemfile.lock checked in doesn't let you know immediately when some change to the ecosystem breaks your setup. Presumably, a developer still has a Gemfile.lock left over from the last time you did a bundle install. Or do gem developers routinely delete their Gemfile.lock and do a fresh "bundle install"?

A developer that is new to the project will indeed find out that something is broken. Unfortunately, he could have a tough time figuring out why, since he has no known good set of versions to start from.

There's no doubt that Mr. Katz's advice is popular and well received. That doesn't make it correct: I think that most of the reasons he gives to support his advice are wrong. However, you are the gem maintainer and must do what you think is right.

Thanks for the discussion, and especially, thanks for maintaining this gem. My job would be much harder without it.

[dougcole]

Thanks @summera, I agree with you that this shouldn't be committed in the repository. Looks at the commit history for Gemfile.lock it looks like it was added accidentally in the first place.