Issue #87 resolved

pylintrc applies disable before enable

eevee
created an issue

I'm trying to use pylint on a large existing codebase, so I want to start with no checks and opt in one at a time to avoid a deluge of complaints about existing issues.

e.g. pylint --disable=all --enable=mixed-indentation worked fine on the command line, but if you put it in an rc file:

disable=all
enable=mixed-indentation

...then no checks actually run. Shoving some logging into pylint.utils revealed that mixed-indentation was being enabled first, then everything was being disabled.

Seems like these should apply in the order they do in the config file, as works on the command line—especially since a generated rc file outright suggests starting fresh with disable=all :) Not even sure what the right workaround is, since I can't use disable more than once.

Seen with both CPython 2.6 and PyPy 2.1 (which implements 2.7).

Comments (7)

  1. Sylvain Thénault

    the pb is that pylint uses logilab.common.configuration to handle that, which itself uses std lib's ConfigParser. And ConfigParser doesn't care about entries order as far as I'm concerned, and I don't think there are ways to tell it to do so.

    Any idea avoiding an extra-dependancy is welcome.

  2. eevee reporter

    Thanks for the quick response to all these tickets!

    I don't think ConfigParser is to blame. OptionsManagerMixIn.load_config_file iterates over provider.all_options, which in turn iterates over provider.options_by_section, which evaluates configuration keys in the order the options are defined. And indeed, in PyLinter.make_options, enable appears before disable.

    Easy fix is, I suppose, to switch these so disable is defined before enable; that order seems strictly more useful (and is suggested in the option help), but on the other hand it might break existing config relying on that order. Would also be nice if the documentation for both of them explained more precisely how they work in configuration files. :)

    I think you can fix the general problem while still using ConfigParser: the constructor accepts a dict_type for changing the class used to store all the parsed arguments. So with a small class that does something like this:

    class ConfigPairDict(object):
        def __init__(self):
            self.pairs = []
    
        def __setitem__(self, key, value):
            self.pairs.append((key, value))
    

    ...config files could use any number of arguments in any order and ultimately have them applied just like on the command line.

  3. Sylvain Thénault

    Yes I would rather like a solution where the order in the file is considered, and as python>=2.7 ConfigParser is sensible to ordering in the file, I would simply fix load_config_file to iter on config values instead of all_options.

    User of python<2.7 would still (randomly) have this bug though.

  4. Log in to comment