retriable
retriable copied to clipboard
kamui
Request: Remove Gemfile.lock from .gitignore
I believe it is best practices to do so in ruby (as it helps ensure consistent testing/debugging) but it's especially relevant here, as nothing in the Gemfile is version locked.
An example why this is needed:
I just forked this repository and ran bundle update (I couldn't use bundle install due to the lack of a lockfile), and I am immediately seeing rubocop erroring out due to the fact two of the cops (Layout/IndentArray and Layout/IndentHash) listed in the config have since been renamed.
My choices are to either:
a) Guess at the intended version of rubocop using the times gem log .rubocop.yml, adding the version lock to the Gemfile and re-running bundle update, or;
b) Update the .rubocop.yml.
Obviously, either solution requires changes to a file tracked by git, which I would then have to pick around.
I thought best practice for rubygems was to not checkout the Gemfile.lock file if your project is a rubygem. Here's a stackoverflow on it: https://stackoverflow.com/questions/4151495/should-gemfile-lock-be-included-in-gitignore
@kamui, hrm. This is from 11 years ago, so I'm thinking it might be outdated. In a gem, the Gemfile.lock applies exclusively to developers who are running things in the context of the gem itself. If you have a dependency on a gem, bundler only looks at the gemspec.
The top answer was last edited 2 years ago and a quick Google seems to show that even recently it's not definitive that libraries/gems should check in Gemfile.lock. Most seem to say no, but a few resources/comments seem to say it has pros and cons for gems.
For this library, it doesn't seem like it would be important? Retriable has no gem dependencies for users of the gem. The only ones in the gemspec are for running tests against it.
Hrm. I'll check out what bundler does tomorrow. There has to be a definitive answer here as to if bundler checks that file.
Honestly the only reason this is important is because of the difficulty that you run into with robocop. Since this gem supports ruby versions that have been EOLed, this gem can't use the latest robocop, which is the most likely to be installed on a dev's machine.
(Robocop no longer supports the minimum ruby version in use here, and the rules change names and options over time.)
I made this because when I wanted to open a PR for this gem, I literally had to do a deep dive into robocop's commit history to find the version robocop version that matched this project.
Even after installiing that robocop though, it becomes difficult if you keep more than one version because without an accurate Gemfile.lock, you can't do bundle exec rubocop.
The alternative to all this I guess would be to put an exact version in the .gemspec and/or Gemfile, but that's literally why a Gemfile.lock exists.
I totally forgot about this, but check out bundler's online documentation on this.
Also, this is in the manpage for bundle install:
THE GEMFILE.LOCK
When you run bundle install, Bundler will persist the full names and versions of all gems that you used (including dependencies of the gems specified in the Gemfile(5)) into a file called Gemfile.lock.
Bundler uses this file in all subsequent calls to bundle install, which guarantees that you always use the same exact code, even as your application moves across machines.
Because of the way dependency resolution works, even a seemingly small change (for instance, an update to a point-release of a dependency of a gem in your Gemfile(5)) can result in radically different gems being needed to satisfy all dependencies.
As a result, you SHOULD check your Gemfile.lock into version control, in both applications and gems. If you do not, every machine that checks out your repository (including your production server) will resolve all dependencies again, which will result in different versions of third-party code being used if any of the gems in the Gemfile(5) or any of their dependencies have been updated.
When Bundler first shipped, the Gemfile.lock was included in the .gitignore file included with generated gems. Over time, however, it became clear that this practice forces the pain of broken dependencies onto new contributors, while leaving existing contributors potentially unaware of the problem. Since bundle install is usually the first step towards a contribution, the pain of broken dependencies would discourage new contributors from contributing. As a result, we have revised our guidance for gem authors to now recommend checking in the lock for gems.
The update on bundler's docs is like their opinion. They made it after the author of the bundler has moved to other projects. I don't see a reason why not use Gemfile if you really want to fix some versions. Gemfile.lock depends on the environment. And it kind of makes it pointless to even have two separate files if you treat them the same.
Also rubocop is a cancer anyway. This literally shows how it creates excessive problems out of thin air.
@Nakilon
I don't see a reason why not use Gemfile if you really want to fix some versions
Normally you only add gems you specifically need in your project in Gemfile. Gemfile.lock will have all the dependencies of these gems. So if you want to lock these dependencies versions you must check your Gemfile.lock, otherwise each bundle install / bundle update will update all dependencies and potentially break stuff.
