feat: Allow all config formats in all config locations

[danrneal]

Steps

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Add a ChangeLog entry describing what your PR does.
• If it's a new feature or an important bug fix, add a What's New entry in doc/whatsnew/<current release.rst>.
• Write a good description on what the PR does.

Description

Type of Changes

	Type
✓	✨ New feature
✓	🔨 Refactoring
✓	📜 Docs

This PR would allow a pylintrc, .pylintrc, pyproject.toml, or setup.cfg in any location that config files are stored. For example, currently pyproject.toml will only be read from the project root but not from the home directory. This PR would allow it to be read from the home directory. This is helpful when creating a global default config as other projects (such as isort) allow this config format in the home director. Let me know if this is a welcome change with or without revision or an unwelcome one.

[coveralls]

Coverage increased (+0.1%) to 91.692% when pulling 13d3f4e on danrneal:allow-all-config-formats into d0591ba on PyCQA:master.

[Pierre-Sassoulas]

I think this is a welcome change, and a very important one, but also a very sensible one that could make a lot of CI/run fails if not done correctly. Could you add tests for this, please ? In particular for the get_config_path function. I'm also going to wait for another review before merging it for this reason.

[danrneal]

I rebased onto master, added typing, and added a test case. Thanks for the input. Let me know if I need more tests or can improve in another way.

[Pierre-Sassoulas]

Thank you for taking my review into account. I don't have enough time right now to check that it's not breaking the current expected order of configuration file priority, Please don't hesitate to ping me if I still did not review it properly by october.

[danrneal]

The only place it may break current order of priority is in the home folder. Previously it only looked for .pylintrc. Now it looks for pylintrc before .pylintrc. In fact it prioritizes configs in the same order in every location now. pylintrc, .pylintrc, pyproject.toml, and lastly for setup.cfg. I updated documentation with the PR to be more clear about priority as well.

[Pierre-Sassoulas]

Sorry for the long time between first fast review and actual review. I don't see a problem here but I'm going to wait for another review before putting it in 2.7.0.

[danrneal]

Sounds good, just let me know of any feedback and/or changes needed :)

[hippo91]

@danrneal thanks for this clear and welcomed PR!
I just have few comments/questions.

[hippo91]

What happens if two or more valid files are found in the same location?
Maybe the doc should explain this.

[danrneal]

I added that they were listed in order or priority. So if .pylintrc and setup.cfg are in the same location it'll pick .pylintrc. Is that clearer or do I need to expand more than just the note?

[hippo91]

Why did the else statement disappear?

[danrneal]

Isn't the else is redundant when there is a yield or return statement inside and if block?

[Pierre-Sassoulas]

I'm moving this to 2.7.1, I think it's addable as a minor feature later.

[AWhetter]

Sorry to jump in so late in the game. I don't think that it makes much sense to look for a pyproject.toml or a setup.cfg anywhere other than in the project because those files store metadata about a specific project. It's in the name of the pyproject file and in the PEP of the file (https://www.python.org/dev/peps/pep-0621/). Those files don't really belong outside of a project, so I can't think of a good reason to look for them anywhere other than the current directory.
Looking for a .pylintrc anywhere other than in the currently working directory also seems out of place. It makes sense to allow it in the current working directory because maybe you want to obscure it from view to keep the project tree looking tidy. But the directories ~/.config and /etc are the places for config files, so I can't think of a reason why you would want to obscure a config file from view in those places.

Side note: For a while I've been feeling like the config system in pylint is not great and it needs a bit of attention. The code itself is pretty unwieldy and I think the user experience of configuration isn't great either. Changes like this make me nervous because some day we'll want to give the configuration the attention it deserves, but that means making breaking changes. So I'd rather not expand the bounds of the configuration system too much so that aren't breaking as much for people later on and so we can focus more on what the config system should do, rather than needing to worry about what we might break.

[Pierre-Sassoulas]

@AWhetter I agree that the configuration need to be redesigned and that we don't want to have too much to break when we do that. I also agree pyproject.toml or setup.cfg makes no sense outside of the current project directory and you convinced me we should not start maintaining and documenting things that do not make sense (especially considering the fact that we had two possible names for pylintrc already .pylintrc and pylintrc).

But isn't etc/ or ~/.config the right place for a global pylint configuration used for all projects on a computer ? I was thinking of maybe using confuse for the configuration redesign and they put their configuration file in XDG_CONFIG_HOME :

Look for configuration files in platform-specific paths. Like $XDG_CONFIG_HOME or ~/.config on Unix; “Application Support” on macOS; %APPDATA% on Windows. Your program gets its own directory, which you can use to store additional data. You can transparently create this directory on demand if, for example, you need to initialize the configuration file on first run. And an environment variable can be used to override the directory’s location.

Source: https://pypi.org/project/confuse/

[AWhetter]

But isn't etc/ or ~/.config the right place for a global pylint configuration used for all projects on a computer

Yes absolutely! I like both of these places for a pylintrc file. But not for .pylintrc, pyproject.toml, or setup.cfg.

[Pierre-Sassoulas]

I think the pylintrc could also be global ? For example you have a default value in pylint, you can change it in etc/ with a pylintrc file, then you can change both in your repository with the local file. I get it would means we need an option for a local config to signal that it's bypassing the global config for all value and define pylint's default unless explicitly overridden. Or do you want to change the name of the file during the refactor ?

[AWhetter]

Yes that's what I meant. pylintrc should be global. .pylintrc, pyproject.toml, and setup.cfg should no be global.

I definitely think that config inheritance is something that we should consider in the future, but we shouldn't implement it now.

[danrneal]

Both isort and black stop going up directories when they get to a .git or .hg directory. But the use case for having a single config for isort, pylint, and black in the home directory is for coding that isn't part of a project. If you had a global default pyproject.toml then your code can still be linted and checked for style even if your code is not part of a project.

I can address the comments in the PR and get it back into ship shape. However, if this isn't the direction to go in, then there probably isn't a lot of value in me doing that. I'll wait for more discussion.

[Pierre-Sassoulas]

I think we could mirror what isort and black do, what do you think @AWhetter ? Maybe we need to refactor this for 3.0 as a real breaking change ?

[Pierre-Sassoulas]

I'm going to close as we're going to move to non global configuration files. Thank you for your contribution and sorry for being indecisive @danrneal