On Wed, Jul 20, 2016 at 8:20 PM, Tim Stumbaugh <stum@hudson-trading.com> wrote:
> Hi,
>
> Since command line flags are processed after config file directives, error
> messages that are disabled in a config file (or in a command line flag that
> appears before --errors-only) are not respected when running in errors-only
> mode.
>
> This appears to be because errors-only mode unconditionally enables all
> messages with a category of 'E' or 'F'.
>
> We have a config file that has the messages that has a few error messages
> disabled (because of highly-dynamic features that we use that pylint can't
> interpret correctly), but we do run pylint in errors-only mode quite often.
>
> A patch that works for us is to change PyLinter.disable_noerror_messages not
> to ever enable messages (but only to disable non error messages). That seems
> like quite a large change though, since a user who only passes --enable (or
> enables messages through the config file) would not get messages in
> --errors-only that they haven't asked for.
>
> Is there an opinion on what patch might be acceptable for the project? Would
> it work to add an extra flag or put extra state in the PyLinter object so
> that it knows which messages have been explicitly disabled?
>
> Thanks,
> tjs
>


Hi,

I think we should not touch the error-only mode, especially since
it does not provide any guarantee that the previous configured
disables or enables are respected, being a mode selection rather
than a verbatim shortcut towards disable=all enable=E (the
same way with --py3k), the mode being to activate all the known errors.

This problem can be of course solved without touching any code,
at least on the CLI level that would be equivalent to

--disable=all --enable=E,F --disable=m1,m2,m3.,

while in the configuration this would be equivalent to

disable=all
enable=E,F
disable=m1,m2,m3

with the only caveat that this is currently not possible, due
to the fact that we do not support duplicate options
in the config files. We still can support this feature with
a custom dict type for the config parser, so that is not necessarily
an unavoidable problem.

These two solutions though have the disadvantages that you will
have to repeat the mantra all the time, but I can't find right now
an alternative.
Having the CLI pragma controls take in account what was activated
or deactivated in the config file leads to confusion
(if I disable X in config file and with the CLI I am doing
--enable=E, should the last part enable X if it was already
disabled? If not, why? How do you detect the rule and what gets enabled
and what not.) This turns into a slippery slope of edge cases and
behavior for which we have to check the documentation all the time.

I would rather introduce a DSL that would alleviate our current
limitations with the binary world of enabled and disabled
messages
(with something that can manage to hand pick only those
messages from a category of messages, while
satisfying some conditions).


Claudiu