It is possible to write plugins which are only a function. At the moment they
are called on each line manually. This allows the function also to be called
on each file once. It works similar to creating the class and calling `run` on
it immediately. The plugin function needs to return a generator.
This is based on the original comment in the `FileChecker.run_ast_checks`
method, but slightly modified as the original comment would've called the
return of the function. But the function could return the reports directly.
This simplifies the changes, reduces the scope of refactors apparently
for refactoring's sake and ensures that the internals are reasonable.
It also airs on the side of preserving information rather than
discarding or overwriting it.
If a user specified `--max-complexity` on the command-line, they
would be told that it did not exist. The same would be true of any
option provided by a plugin. This is because we parse the command-line
arguments twice in Flake8 -- the first time to specify the verbosity
and destination for logging, the second time to actually execute Flake8.
Since plugin options are not registered to start with the first time,
they are not valid options. So when we first parse the options, we should
only attempt to parse the ones which we know about.
Closes#168
Also refactor our statistics module to be a bit smarter and less
namedtuple happy. The Statistic class had no reason to be a tuple,
I have no clue why I wrote it that way last night.
Handle errors reported in empty files
*Description of changes*
Some plugins return errors in empty files which previously caused an IndexError.
*Related to:* #157
See merge request !71
On Flake8 2.x we added the information about the implementation,
version, and operating system to the --version output to make helping
users easier. In short they can pretty simply just give us the output
from
flake8 --version
And we can get a lot of the information that we need.
Previously, pycodestyle never introspected the argument names for
classes except to require that ``tree`` be an argument it could pass.
For Flake8 3.0, we lifted that restriction, but old plugins seem to
have cargo-culted their __init__ signature to be
def __init__(self, tree, builtins=None):
For some yet unknown reason. This was causing an AttributeError. By
updating flake8.utils.parameters_for to return a dictionary that
indicates whether the parameter is required or not, we can side-step
this by simply ignoring the parameter if it has a default value and
we cannot provide it.
Closes#151
Previously Flake8 parsed both
max-line-length = 110
And
max_line_length = 110
From the config file without issue. When we updated our logic, I forgot
to test for that and we lost that behaviour temporarily.
Closes#152
If somebody explicitly has a `.flake8` file, presumably they intend to
put flake8 configuration in it, so prefer it to the generic `setup.cfg`
and `tox.ini` from pycodestyle.
This relies on two things:
1. Properly configuring flake8-import-order to use that style
2. Properly configuring flake8-import-order to know that flake8 is our
application name.
ConfigFileFinder should absolutely handle broken/invalid config files
by refusing to try to parse them. Here we catch the ParsingError,
log the exception, and then return normally. The RawConfigParser
instance is perfectly valid still and will behave as if nothing had
been read and we just need to indicate that we didn't find any files
worthy of reading.
Related to: https://github.com/PyCQA/pycodestyle/issues/506
This adds E501 which is actually a poor test. Currently,
pep8.maximum_line_length does its own check for noqa instead of relying
on the Checker. See also: https://github.com/PyCQA/pycodestyle/pull/539
This allows us to handle --show-source in our formatters by default.
This also adds the physical line information to the Error class instead
of passing it to is_inline_ignored. This allows us to avoid using
linecache in our formatters.
Python 2.7's ConfigParser module does not allow for the behaviour we
have documented for config files in Flake8 3.0. To compensate for that,
we add a dependency on the configparser backport on PyPI for Python 2.7
We move the logic to add or remove a plugin from the default ignore
list to individual methods on the Plugin class (Plugin#enable,
Plugin#disable) and use that when registering and parsing options.
If the plugin is off-by-default, Plugin#register_options will use
Plugin#disable. When parsing options via Plugin#provide_options, if
the plugin has been specified in --enable-extensions then it will be
re-enabled via Plugin#enable.
