I'm trying to set up my build system to use pylintrc files during the build.
For example, in my pylintrc file I was going to do something like:
Which (of course) doesn't work:
$>pylint --rcfile=pylintrc my_file.py
backports.configparser.DuplicateOptionError: While reading from 'pylintrc' [line 24]: option u'disable' in section u'MESSAGES CONTROL' already exists
Once I realised that they are INI files, it made more sense. INI files do not allow for multiple values for a key (within a section), and different parsers handle this case differently.
Since strict=True was being used by the Python parser, it raise this exception.
The annoying part is that you can pass multiple 'enable/disable' arguments on the command line.
In fact, there is an example in the documentation auto-generated by `pylint --generate-rcfile`:
"If you want to run only the classes checker, but have no Warning level messages displayed, use '--disable=all --enable=classes --disable=W'"
But this cannot be done in the pylintrc file. Annoying, since I was not going to use the command line and changing my build system to do would be non-trivial.
I would like to see the pylintrc file have at least as much capability as the command line. I would like to propose to extend the syntax to provide an ordering.
Today we have "disable" and "enable", with "enable" taking precedent.
Perhaps we could change the syntax to be "disableX" "enableY", with X and Y being positive integers. Higher precedence would be determined by higher integers. "enable" would still have precedent within a given integer level.
It would be backwards compatible, with 'disable' being an alias for 'disable1' and 'enable' being an alias for 'enable1'.
would be equivalent to:
There could easily be a better way to do that this, or some pattern/syntax people already use when dealing with INI files in order to work around this.
I would like to see the pylintrc file have at least as much capability as the command line.
Let me know what you think,