Figure out a better way of registering options?

[AWhetter]

All of the config parsers (the CLIParser and the IniFileParser) need the option definitions and so does the Configuration. Registering a checker means registering options, which means the PluginRegistry needs a callback function to give these options to all of these objects.

[Pierre-Sassoulas]

I would not mind for the processing of option to be handled by argparse or even better confuse or click in a simple manner. Optparse is deprecated since python 3.2. Even if Optparse was state of the art, the Mixin classes are really confusing for me. I think it's something we need to keep in mind : it's probably easier to nuke the whole thing and start fresh with a newer library than doing it little refactor of Optparse by little refactor of Optparse.

The checker could also use composition instead of inheritance in order to get their options. It would break the coupling we have right now between option parsing and code analysis. Changing the way option work is made very difficult because of this coupling. Test are using the checker by giving option to Optparse, so the refactor of option registering is huge because of that if you change the option registering you need to change the checker tests too (!).

So I think it might be necessary to first make the BaseChecker an independent base class before actually doing anything to make options registering better.

[DanielNoord]

@Pierre-Sassoulas Is there a reason why options are given to BaseChecker? Can pylint be ran without instantiating a PyLinter class?

To me it seems much more logical to add all options to PyLinter at once and allowing all checkers to access them from self.linter or from a util function that gets them from the PyLinter class. This would mean that we would move all current optdicts to a separate file/module which gets loaded once by PyLinter on initialisation.

Problems to consider would be:

1. What is the performance effect of loading unnecessary options (ie, options from disabled checkers/extensions)
   I think this is marginal compared to the double loading we often do now
2. How can extensions or checkers add options to the PyLinter.options attribute?
3. How do organize the main list of optdicts?

[Pierre-Sassoulas]

I think it's theorically possible to launch a single checker but in practice we never do that and always use pylint through the pylinter. Might not be true for plugins ?

[DanielNoord]

Yeah, that's what I was wondering. Do we have an "plugin expert" who would know this?

[DanielNoord]

@Pierre-Sassoulas I think we can close this? There is still #5829, but I think that deserves its own issue and doesn't necessarily fall under this one.