Fundamentally on Flake8 2.x using -q altered the format of the errors
(and the behaviour a little) so it makes the most sense to implement
this logic with formatters rather than messy logic spread throughout
the project.
The FilenameOnly formatter will keep track of filenames already reported
and only print the name once while Nothing will print nothing.
Closes#180
Set-up and stop our formatter
*Description of changes*
Make `--output-file` work consistently (especially without verbose logging)
*Related to:* #180
See merge request !86
Update documentation to separate parameter types
This is the documentation update separated from !80 which should be pretty uncontroversial. I already applied the comment on the documentation here.
See merge request !83
Handle multiline strings with '# noqa'
*Description of changes*
I had overlooked a usecase of Flake8 where people use `# noqa` at the end of a multi-line string. This addresses that oversight
*Related to:* #177
See merge request !85
In Flake8 2.x we allowed people to use # noqa at the end of a multiline
string to ignore errors inside the string (e.g., E501). Being blissfully
ignorant of this, I never accounted for it in Flake8 3. This fixes the
oversight and allows multiline statements to have the # noqa at the end.
Closes#177
It updates the documentation to separate which parameters are static and
which are changed on each line. Using the latter parameters on plugins which
are only run once per file isn't very sensible.
Force flake8 test to below 3.x
The current version (0.8) of `flake8-import-order` still uses `parser.config_options` and so all builds fail because it installs Flake8 3.x.
Now the repository of that plugin already accounted for that but as long as it isn't released it'll cause all new builds to fail. Alternatively I can repurpose this merge request to actually enforce a newer version of `flake8-import-order` which supports Flake8 3.x.
See merge request !84
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.
Check for both os.path.sep and os.path.altsep
*Description of changes*
When normalizing paths, we want to handle the following cases:
- Someone is using a Windows-style path on Windows
- Someone is using a Unix style path on Unix
- Someone is using a Unix style path on Windows
os.path.sep will handle the native directory separator character while os.path.altsep (when set) will handle alternate separators. Further, os.path.abspath does the right thing on Windows when handed a Unix-style path.
*Related to:* #175
See merge request !81
In the case where alternate separator is None, we use '' which will
always be in any string. We want to skip that case.
Also we only run our tests on AppVeyor, not all of our testenvs.
When normalizing paths, we want to handle the following cases:
- Someone is using a Windows-style path on Windows
- Someone is using a Unix style path on Unix
- Someone is using a Unix style path on Windows
os.path.sep will handle the native directory separator character while
os.path.altsep (when set) will handle alternate separators. Further,
os.path.abspath does the right thing on Windows when handed a Unix-style
path.
Related to #175
The documentation for the `FileProcessor` class used `indect_char` while the
class itself uses the more sensible name `indent_char`. This updates both the
docstring as well as the documentation.
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.
For the sake of IDEs, check filename for exclusion even if the file is directly
named in the command line.
Also, if the filename is "-" (stdin) check the provided display name for
exclusion.
Also, avoid calling path checking functions on the "-" filename:
* fnmatch.fnmatch()
* os.path.isdir()
* os.path.exists()
Document flake8-polyfill in compatibility section
*Description of changes*
Document the existence and usage of the flake8-polyfill section.
Closes: #158Closes: #161Closes: #167
See merge request !77
Yesterday we released the flake8-polyfill package to help with Flake8
compatibility issues. This adds documentation to Flake8 to help people
use that and to guide them towards it.
Fix git config parsing
Because the `git config --get --bool <option>` external command adds an extraneous newline for readability purposes, that character need to be stripped for proper parsing.
*Related to:* #170
See merge request !75
Since the "git config" command adds a newline to the end of its output, the extraneous whitespace needs to be stripped out for proper parsing.
Fixes#170
Add OptionManager#parse_known_args
*Description of changes*
Add `parse_known_args` to our `OptionManager` interface so plugin flags can be specified. This provides similar behaviour to argparse's `parse_known_args` method on its `ArgumentParser`. When we transition to argparse, we'll be able to take direct advantage of that.
*Related to:* #168
See merge request !74
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
If users do `from flake8.api.legacy import *` we only want them to get
get_style_guide imported. The other classes are not meant to be created
by users.
We need to initialize part of the Application so we can set options
passed by the user, but we also want to delay making things, e.g.,
- Formatter
- Style Guide
- etc.
Until we have the options solidified so we don't have to do annoying
things.
Add the statistics module
*Description of changes*
Start adding support for `--statistics` and legacy `get_statistics` API.
*Related to:* (Add bug number here)
See merge request !73
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.
