There was a *very* subtle bug in how we handle blanket select statements
with error codes that are in our DEFAULT_IGNORE. In the specific case,
users were specifying ``--select E`` and E126 was not being properly
reported. This unveiled further logic bugs as we refined this.
Closes#318
By splitting out the logic to retrieve and return the formatting class
for an application, we can test it more easily and increase our test
coverage of this critical logic.
Refs #320
When we read in a file on Python 3, we use the tokenize module to detect
the coding pragma at the top of the file. We then use that to decode the
rest of the file. However, when we were receiving stdin, we would not do
that.
This updates ``stdin_get_value`` in a backwards compatible way to check
for that coding pragma and then fall back to UTF-8 if necessary.
Closes#306
Apparently there are some cases where the git hook will not find files
to run the checks against (e.g., when amending a commit message). In
those cases, it's best not to attempt to run any checks and to allow the
hook to exit successfully.
Closes#303
When we receive a SyntaxError, it is not guaranteed to have a token that
includes the physical line causing the issue. If it does not, we now
will avoid trying to determine the number of rows and columns that are
actually there and default to what the error tells us.
Closes#279
In our setuptools integration command, we were attempting to avoid
checking each submodule in the packages list. This was done without
recognizing that two modules may start with the same prefix, e.g.,
- foo
- foo_bar
- foo_biz
In this case, we only ever checked ``foo``. By appending a '.' to the
end of each package name, we avoid this since we only care about
deduplicating submodules, e.g.,
- foo
- foo.sub
- foo.sub.sub
Closes#295
By ordering the plugins, --version becomes reproducible so that it
continuously prints the same output (provided the plugins have not
changed).
Closes#297
Instead of displaying the path to the temporary directory, as we always
have, it's been requested that we instead display the path to the file
that was copied to the temporary directory.
Closes#244
This adds two new methods to the BaseFormatter class:
- beginning
- finished
These will indicate when Flake8 begins and finishes processing a file.
Closes#251
Some PyFlakes messages weren't covered by unique messages, making them
impossible to select/ignore. This is now fixed.
To ensure we don't regress in the future, a test has been added that fails if
there's any uncovered messages.
Previously we added support so users can do:
$ flake8 bin/executable
But this broke the fact that git hooks shouldn't check things like
reStructuredText doc files. This commit restores that functionality but
will cause bin/executable to be ignored in the git hook. This seems fair
since folks can amend their filename patterns to include it explicitly.
Closes#268
Handle SyntaxErrors in a slightly smarter way
SyntaxErrors are strange and mystical beasts. On top of the problems we
encountered previously in GitLab#237, it's now apparent that
SyntaxErrors can also occur across multiple lines (in fact, across the
rest of a file). In the event of a "multi-line" SyntaxError, we need to
determine what row to report and what the column number is.
For now, we're going to use the row number of the first line and limit
the column number to be less than the end of the line. It may not be
perfect, but it is slightly better.
Related-to #237Closes#259
cc @arcanemagus
See merge request !151
By default, when discovering files for users, we use the filename
patterns to determine whether or not we should check that file. However,
when a user provides the path to a file, we should instead skip checking
the name against the filename patterns provided.
For example, in Flake8 2.6 this worked:
$ flake8 bin/script.py
$ flake8 bin/script
But prior to this commit only
$ flake8 bin/script.py
works. This commit will skip the filename pattern check if the user
provides the path explicitly which allows
$ flake8 bin/script
to work again as expected.
Closes#266
SyntaxErrors are strange and mystical beasts. On top of the problems we
encountered previously in GitLab#237, it's now apparent that
SyntaxErrors can also occur across multiple lines (in fact, across the
rest of a file). In the event of a "multi-line" SyntaxError, we need to
determine what row to report and what the column number is.
For now, we're going to use the row number of the first line and limit
the column number to be less than the end of the line. It may not be
perfect, but it is slightly better.
Related-to #237Closes#259
When we refactored our decision process to fix#239, we broke a subtle
corner case where extensions that are not off-by-default are to be
reported.
This further refactors that logic and adds specific tests around it to
ensure it works as expected and doesn't regress.
Closes#257
When running the git hook, even though the appropriate config file is
found and processed, the exclude patterns and paths were not being
corrected to account for the temporary directory that we copy the files
into.
Related-to #223
If we handle an exception, or early exit, or really anything, we should
exit non-zero (and we used to). This was a minor oversight.
Closes#209Closes#248
Do not print the source when provided with -q
When users specify any number of -q's on the command-line, we should not
show the source even if they have otherwwise configured Flake8 to do so.
Closes#245
See merge request !140
When users specify any number of -q's on the command-line, we should not
show the source even if they have otherwwise configured Flake8 to do so.
Closes#245
When we enable a plugin (when it's provided in the --enable-extensions)
plugin, we need to remove it both from the extended default ignore list
and the plain ignore list.
Closes#239
Change how we initialize our git hook application
Look for configuration files in the current directory while checking the
files in the temporary directory.
Closes#223Closes#210
See merge request !136
Previously, we didn't handle the case where an error code was implicitly
ignored (by not being in --select) and implicitly selected (by not being
in --ignore). This means we need to update StyleGuide#_decision_for and
StyleGuide#is_user_selected to handle these cases.
Closes#242
Related-to #239
Related-to !132
