Should .pylintrc contain all settings explicitly or just overrides

[sisp]

Question

What's the best practice regarding Pylint's configuration settings?

1. All settings are explicitly specified, even when most or all settings use default values.
2. Only overrides are specified, i.e. default values are used implicitly unless explicitly overridden.

I've not been able to find an answer to this question anywhere. Personally, I find materializing all settings explicitly quite verbose and difficult to maintain given the large number of settings. Also, it would be hard to tell which settings just use default values and which settings use custom values. On the other hand, changes in default values with a new release of Pylint would not cause errors with explicit settings. But then again some releases introduce new settings whose values would not be set explicity either unless they are manually added to the config, so it's easy to end up with a mix of explicit and implicit (default) settings.

Would the best practice be to have a config only with settings overrides (so no explicit default values) and use a package version specifier that pins the major and minor version (i.e. the version specifier only contains bug fix releases, e.g. >=2.14,<2.15)?

Documentation for future user

I think the Pylint documentation should describe the best practices for using Pylint, including best practices for the config and version specifier.

Additional context

No response

[Pierre-Sassoulas]

I think the fact that we can generate the whole configuration with a command send the wrong message on this issue. We need(ed?) this command as a kind of documentation of the configuration. It's indeed better to have a minimal pylintrc and trust pylint's default value for easier maintenance imo. (Unless we have a migration/suggestion tool for the configuration but this is another high effort issue that I can't link as I'm on mobile).

I would be interested in other opinions on this.

[sisp]

Thanks for sharing your thoughts on this topic. 🙏

What's your recommendation regarding the version specifier for Pylint? Pinned to major and minor version?

By the way, I'd be happy to contribute the results of this discussion to the docs.

[Pierre-Sassoulas]

Thank you for being willing to contribute.

There's a paragraph on updating pylint in the doc, I can't link as I'm on mobile, please search for 'patch release' or 'versionning'.

[DudeNr33]

I would be interested in other opinions on this.

For the final pylintrc I'm +1 on only specifying the options where something different than the default is needed.

For generating the example configuration with the --generate-rcfile option I like that all possible options are included together with their respective documentation. This gives new users a good overview what configuration options are available, what they mean, and where they must be placed in the configuration file.
Sure, you could also get this information from the docs - but I like that I can just go through the generated config, directly understand and edit each option I encounter, and finish the configuration without ever having to leave the editor.

The only thing I noticed is that some options are commented out, while others are not. Haven't looked in detail where this behaviour is coming from.
I would prefer that all options are commented out in the generated rcfile, and if I want to override the default I just uncomment them. See argument-naming-style and argument-rgx here for example.

[BASIC]

# Naming style matching correct argument names.
argument-naming-style=snake_case

# Regular expression matching correct argument names. Overrides argument-
# naming-style. If left empty, argument names will be checked with the set
# naming style.
#argument-rgx=

[sisp]

There's a paragraph on updating pylint in the doc, I can't link as I'm on mobile, please search for 'patch release' or 'versionning'.

https://pylint.pycqa.org/en/latest/user_guide/installation/upgrading_pylint.html

Just for completeness. 😉