Specify -c .rubocop.yml for rake rubocop

[martinemde]

What was the end-user or developer problem that led to this PR?

This avoids the problem where an existing .rubocop.yml is found in the user's home directory that causes errors or misconfiguration. For example, it was picking up my ~/.rubocop.yml and complaining about Rails cops.

What is your fix for the problem, implemented in this PR?

Specify the .rubycop.yml config explicitly in the rake task.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[simi]

Can't you just use bin/rubocop with any arguments you would like to? Maybe we can remove this rake task at all, it seems redundant and update docs.

[deivid-rodriguez]

Seems like a good idea.

[simi]

@martinemde would you mind to update the PR? We can also merge this and I can do in followup if preferred.

[martinemde]

I can update when I get back to the computer. Are the binstubs updated automatically somehow though?

[deivid-rodriguez]

No, our current binstubs are maintained manually.

[martinemde]

I think we should keep the rake task. rake rubocop installs the correct versions of rubocop gems according to the Gemfile at tool/bundler/lint_gems.rb, then runs rubocop using bin/rubocop. This is also part of the lint check in the github actions.

Interestingly, specifying --config reliably speeds up the run, about 13% faster overall. I added it in to the binstub instead of the rake task so that it's used every time.

[simi]

I'm a little confused in here @martinemde. This seems problem with your specific setup. How do you handle this in other projects? Do you specify -c manually or do you change binstub to specify -c projectwise? 🤔

[martinemde]

@simi I'm really not sure why this is showing up now. I have some basic defaults for rubocop in ~/.rubocop.yml for projects that don't have rubocop. Rubocop docs say that they ignore this file but it loads it instead. See here with --debug.

 rake rubocop\[--debug\]                                                                                                                           Tue 22 14:10:49
(in /Users/martinemde/Projects/oss/rubygems)
Bundle complete! 2 Gemfile dependencies, 14 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
For /Users/martinemde/Projects/oss/rubygems: configuration from /Users/martinemde/Projects/oss/rubygems/.rubocop.yml
configuration from /Users/martinemde/.gem/ruby/3.2.2/gems/rubocop-performance-1.14.2/config/default.yml
configuration from /Users/martinemde/.gem/ruby/3.2.2/gems/rubocop-performance-1.14.2/config/default.yml
Default configuration from /Users/martinemde/.gem/ruby/3.2.2/gems/rubocop-1.52.1/config/default.yml
AllCops/Exclude configuration from /Users/martinemde/.rubocop.yml
Error: `Rails` cops have been extracted to the `rubocop-rails` gem.
(obsolete configuration found in /Users/martinemde/.rubocop.yml, please update it)
Finished in 0.09444499999881373 seconds
rake aborted!
Command failed with status (2): [bin/rubocop --debug...]
/Users/martinemde/Projects/oss/rubygems/Rakefile:230:in `block (2 levels) in <top (required)>'
Tasks: TOP => rubocop => rubocop:run
(See full trace by running task with --trace)

My .rubocop.yml has some Rails cops in it, so it seems that when it reads that file for a single AllCops/Exclude pattern, it's not properly ignoring unrecognized cops.

The change seems harmless to me, and it's a bit faster. It works around an apparent bug in rubocop for those of us that move between a lot of different ruby projects. If you see a negative to merging this, we can close it.

[simi]

I'm just trying to prevent fixing user problems in rubygems codebase. Would you mind to open issue in rubocop instead? 🤔 It could be also related to strange setup of rubocop in this repo and maybe we will get some hint how to fix it. 🙏

[martinemde]

I've tracked the problem down to an unintended behavior in rubocop. I'm fine not merging this, but I also don't think it hurts anything to merge it and it saves a small amount of time every run. I'll link the rubocop issue back here when I submit it.

[martinemde]

This is ultimately caused by rubocop/rubocop#12147 which is, imho, a rubocop bug. Let's just leave our rake rubocop as is and close this. Thanks for pushing a bit more on this @simi.

[deivid-rodriguez]

@martinemde I've been there too. Thanks for fixing things at the right place.

In case it helps, see rubocop/rubocop#8176 and other linked PRs where I thought I had fixed very similar issues 😆.

[deivid-rodriguez]

By the way, if this speeds up loading RuboCop, and we have an explicit binstub, I don't think it hurts at all to be explicit about the configuration.

[simi]

This is ultimately caused by rubocop/rubocop#12147 which is, imho, a rubocop bug. Let's just leave our rake rubocop as is and close this. Thanks for pushing a bit more on this @simi.

Glad to see this fixed at proper place.

By the way, if this speeds up loading RuboCop, and we have an explicit binstub, I don't think it hurts at all to be explicit about the configuration.

Indeed, now we can open another discussion about speed performance. If that makes sense, let's merge this, just add comment in binstub explaining the reason for this.