Configuration parsing fails if options for an unused extension are present

[Mr-Pepe]

Bug description

I run pylint twice, once without pylint.extensions.docparams and once with. Both use the same pyproject.toml configuration file. This was not a problem until 2.14.0 but now the first call crashes because the docparams options are not recognized.

Configuration

[tool.pylint.master]
accept-no-param-doc = "no"
accept-no-raise-doc = "no"
accept-no-return-doc = "no"
accept-no-yields-doc = "no"

Command used

pylint src

Pylint output

pyproject.toml:1:0: E0015: Unrecognized option found: accept-no-param-doc, accept-no-raise-doc, accept-no-return-doc, accept-no-yields-doc (unrecognized-option)

Expected behavior

Unused options do not lead to a crash or section names in pyproject.toml are honored.

Pylint version

pylint 2.14.0
astroid 2.11.5
Python 3.9.5 (default, Nov 18 2021, 16:00:48) 
[GCC 10.3.0]

OS / Environment

Kubuntu 21.04

Additional dependencies

No response

[DanielNoord]

I think this sort of use-case might warrant an additional discussion. Running two versions of pylint with a single configuration file was not one of the things we had in mind when we worked in the configuration refactor for 2.14. I also don't know if we want to explicitly support it.

For now I'd suggest disabling unrecognized-option. You could also do pylint --accept-no-param-doc=no etc. in your second invocation. Then you could keep using the same file without disabling the message.

[Mr-Pepe]

I thought that adding the options to the [tool.pylint.parameter_documentation] section might help but the release notes state:

The main checker name is now main instead of master. The configuration does not need to be updated as sections' name are optional.

Is that going to change in the future?

[DanielNoord]

I thought that adding the options to the [tool.pylint.parameter_documentation] section might help but the release notes state:

The main checker name is now main instead of master. The configuration does not need to be updated as sections' name are optional.

Is that going to change in the future?

I don't think so. Not requiring section names makes the file a little bit more flexible. There is no reason for us to require them, so why would we?

The only reason we could want them is if we would not emit unrecognised-option for options that are in a section of an extension that is unloaded. But that's technically infeasible: we don't know the associated section name for an extension if we haven't loaded it. So the only way to recognise if an extension's option is in an extension's section is by loading the extension, which would stop the unrecognised-option message anyway.

[Mr-Pepe]

That's unfortunate but makes sense. I will disable unrecognized-option for the time being. Thank you for the prompt replies! :)

[DanielNoord]

No worries! I'm going to put this on the milestone for our next minor release so we make sure to take a decision before releasing it (which will probably in a couple of months).

[Pierre-Sassoulas]

I think it would make sense to hard-code every extensions checker's options, and every deleted messages msgid/symbol (we already have a deleted messages list) and treat them differently with a message that could be disabled without touching bad-option-value and unrecognised-option. We discussed that during implementation but I did not realize that the use case of using the same configuration for two calls of pylint existed.

[DanielNoord]

I think it would make sense to hard-code every extensions checker's options, and every deleted messages msgid/symbol (we already have a deleted messages list) and treat them differently with a message that could be disabled without touching bad-option-value and unrecognised-option. We discussed that during implementation but I did not realize that the use case of using the same configuration for two calls of pylint existed.

I'm really against any form of hard-coded list. I already kinda dislike the deleted messages list. How can any new or somewhat experienced contributor now that they need to add a message there? It really raises the bar for entry for maintainers/contributors. Same goes for any other hard-coded list which becomes necessary for correct functionality.

[Pierre-Sassoulas]

There's no other way than a hard coded list for deleted messages to avoid msgid collision. We have a "hard coded" list of messages in checkers originally, so it's just moving code around when you delete something. It's just data, it could be a json. Besides casual contributors are not supposed to take decision regarding removal of features.

For extensions we don't have to hard code it, we could recover the options dynamically.

[DanielNoord]

There's no other way than a hard coded list for deleted messages to avoid msgid collision. We have a "hard coded" list of messages in checkers originally, so it's just moving code around when you delete something. It's just data, it could be a json. Besides casual contributors are not supposed to take decision regarding removal of features.

For extensions we don't have to hard code it, we could recover the options dynamically.

Yeah, I understand the necessity (and I think this is something for another topic). But even after having contributed to pylint for over six months I still don't know/understand all of its peculiarities. There are utility functions I have never used or seen for example. And that's after having worked on the typing for so long.
Hard-coded lists add unnecessary complexity imo.

But let's get back to the discussion in this issue: do we want to support this natively? Or should users use a workaround like adding the additional options on the command line as well?
I'm -0.5/0 on it myself. It's quite a niche use case and using the workarounds seem somewhat enough for me.

[Pierre-Sassoulas]

I think we're forcing users to cleanup their pylint configuration instead of letting them choose if they want to (they have to disable a valuable warning if they don't want to). Another use case that is probably happening a lot as long as we don't have sane default or template : they copy paste a pylint conf online and comment an extension they don't want. Now they have to disable unrecognised-option and not be warned if there really is an unrecognised option, or they have to remove the option related to the extension the commented out (I.e. have to clean their pylint configuration).

[DanielNoord]

For me unrecognised-option is similar to useless-suppression: it's an informational message telling you that you could potentially clean up your code/configuration. If you don't want to receive such messages you can disable them completely.

We could include unrecognised-option in the discussion in #3512. However, I believe there is a difference between useless-suppression and unrecognised-option. As unrecognised-option can also warn you about misspelled options or renamed options that no longer work. That in itself is (for me) a reason to enable this by default and have users who don't want to receive such informational messages disable it once in their configuration. There is more benefit to this message than for some of the other informational messages.

I do think we could have communicated this a little better and should perhaps add some comment about this in our release notes summary.