New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't load exclusions from personal files when passing a config with a custom name #8239
Don't load exclusions from personal files when passing a config with a custom name #8239
Conversation
What do you call personal configuration? Some examples might help understand better the problem you're trying so solve. |
Hi @bbatsov, sorry for not being clear. When I talk about personal configuration files, I mean configuration files in either Currently these files are not very useful IMO because they get loaded in situations where you don't want them loaded. See for example #7433. In my opinion, they should get only loaded as a fallback when the project has no specific rubocop configuration, or no explicit configuration is being passed to the CLI. I'm submitting a series of PRs to fix these issues.
A practical example of this specific fix would be when trying to add some initial rubocop configuration to a project. You might want to first try different "template" configurations with different settings, and the |
By the way, if we can find a better terminology, I'm happy to change this and the already merged changelog entries. Maybe "user configuration" is better since it matches more closely the terminology used by the code. I've also seen "global configuration" used. |
Agreed. I had almost forgotten about them at this point. |
Me too! I tried using them at some point but eventually gave up, because they kept getting in the middle. Then I saw #7433 and realized other people were trying to use them too, so I decided to give it another try. |
dd90cdb
to
9fe7001
Compare
I rebased this PR and moved the changelog entry in response to the new release 😃 |
I think you should also update the docs to reflect this. |
…custom name If passing a configuration with a custom name, like `rubocop --config-file .my_custom_project_config.yml`, that configuration should act as the project configuration and we want personal configuration files disregarded. That's actually the only case where `find_files_upwards` can return an empty list, because when given an existing `.rubocop.yml` as the starting point, it will at least return that file, and the fallback to personal config files will not be applied. Well, there's another case where `find_files_upwards` could return an empty list, which is when giving it a non existent file as the starting point. However, I don't think that ever happens in real life, and in tests it was only happening once, and due to a typo I believe. So, we can completely remove the explicit fallback to look for exclusions in personal configuration files.
9fe7001
to
2e02a04
Compare
@bbatsov I added a note about the Regarding the behaviour of looking up the highest config file to look for exclusions, there's this: https://github.com/rubocop-hq/rubocop/blob/master/docs/modules/ROOT/pages/configuration.adoc#include-and-exclude-are-relative-to-their-directory. In my opinion, the problem with that docs is that they don't explain why this is done differently from everything else. I'm currently investigating the why, since I think there's no good reason for this and all these code could eventually go. But until then I'm not sure I can improve those docs. From the current wording I don't think it's implied that user configuration files should be searched, so I'd say this is just a bug fix that doesn't need documentation. |
Fair enough! Thanks for tackling this! |
No problem! I'll follow up with more stuff! |
If passing a configuration with a custom name, like
rubocop --config .my_custom_project_config.yml
, that configuration should act as the project configuration and we want personal configuration files disregarded.That's actually the only case where
find_files_upwards
can return an empty list, because when given an existing.rubocop.yml
as the starting point, it will at least return that file, and the fallback to personal config files will not be applied.Well, there's another case where
find_files_upwards
could return an empty list, which is when giving it a non existent file as the starting point. However, I don't think that ever happens in real life, and in tests it was only happening once, and due to a typo I believe.So, we can completely remove the explicit fallback to look for exclusions in personal configuration files.
[Fix #issue-number]
(if the related issue exists).master
(if not - rebase it).bundle exec rake default
. It executes all tests and RuboCop for itself, and generates the documentation.