This is enabled by default in later versions of Rubocop. Making this
change now removes this conflict for people running later versions.
Automatically fixed with `rubocop -a`
This commit does two things:
1. Move development dependencies back to gemspec
2. Restrict versions of some gems
It should also be noted that the recommendation is to commit
Gemfile.lock, however in this case it is not possible to do so:
3. Why we don't commit Gemfile.lock
Each of these requires a more detailed discussion:
1. Move development dependencies back to gemspec
9691355 originally moved all these dependencies into the Gemfile:
https://github.com/varvet/pundit/pull/435
The recommendation in the docs seems to be to use the gemspec for
development dependencies:
https://bundler.io/guides/creating_gem.html#getting-started
2. Restrict versions of some gems
While we want to be as flexible as possible with the gem's production
dependencies, we need to be more specific with our development
dependencies. In particular gems developed against one version of
Rubocop cannot be expected to work with later versions, since Rubocop
adds and renames cops in new versions.
In particular version 0.70.0 renames a cop which we are specifying,
resulting in the following errors.
.rubocop.yml:81: `Style/TrivialAccessors` is concealed by line 96
Error: The `Layout/IndentHash` cop has been renamed to `Layout/IndentFirstHashElement`.
(obsolete configuration found in .rubocop.yml, please update it)
Rubocop version 0.67.2 passes without issues on the latest ruby version,
but is incompatible with 2.2.x and earlier. 0.57.2 is the latest version
which works everywhere.
Note that when running `gem build pundit.gemspec` we get warnings about
some open-ended dependencies:
WARNING: open-ended dependency on activesupport (>= 3.0.0) is not recommended
if activesupport is semantically versioned, use:
add_runtime_dependency 'activesupport', '~> 3.0', '>= 3.0.0'
However, I feel OK about these being loose, and since this gem is not so
often maintained, I'd prefer not to place an upper limit on the
runtime_dependency. The other gems with open-ended dependencies are also
part of Rails, so I believe they'll need to be the same version as
activesupport, which is why they have the same version constraint.
For the gems where we don't specify any version constraint we also get
this warning. For most of these (eg. pry) we genuinely don't care what
version is used.
3. Why we don't commit Gemfile.lock
When this gem was created the standard practice was to gitignore the
Gemfile.lock, but the guidance has changed:
> 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.
https://bundler.io/man/bundle-install.1.html#THE-GEMFILE-LOCK
The intention is that by committing the Gemfile.lock we ensure that all
developers of this gem have the same dependencies.
HOWEVER, we are currently supporting ruby 2.1 and 2.2. Newer versions of
some gems (eg. i18n, which is required by activesupport) are only
compatible with ruby 2.3 and up, so a lockfile compatible with the
latest version of activesupport (which is a runtime dependency) will not
be compatible with these versions.
The impact of this is that we can't commit the lockfile without also
dropping support for versions 2.1 and 2.2.
Duncan Stuart