Assign missing codes to PyFlakes messages
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.
See merge request !159
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.
Only force files to be included when run from CLI
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
See merge request !157
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
Skip filename pattern check for provided files
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
See merge request !153
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
Fix subtle reporting bug for default on plugins
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
See merge request !148
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
Create sub-sections for different release series
When looking at the documentation, the release notes section on the
sidebar was incredibly long, due to the number of releases available.
To make this more usable, I've split the release notes index into
sections for each release series (e.g., 3.x, 2.x, etc.). This allows
documentation users to open the release notes sidebar section, and then
select which series they want. That will expand and let them pick the
version.
See merge request !145
Add a man page for Flake8
Document Flake8 for users expecting `man flake8` to work and include the
man page in Flake8's documentation.
Closes#247
See merge request !146
Correct exclude paths in git hook
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
See merge request !147
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
When looking at the documentation, the release notes section on the
sidebar was incredibly long, due to the number of releases available.
To make this more usable, I've split the release notes index into
sections for each release series (e.g., 3.x, 2.x, etc.). This allows
documentation users to open the release notes sidebar section, and then
select which series they want. That will expand and let them pick the
version.
Remove reference to OpenStack Swift
This section of the docs could be read as pointing out the project as a
bad example. It was not intended this way, but I would like to avoid
anyone interpreting it this way. As a result, we'll continue to use
their configuration section as an example but not name names.
Closes#228
See merge request !143
This section of the docs could be read as pointing out the project as a
bad example. It was not intended this way, but I would like to avoid
anyone interpreting it this way. As a result, we'll continue to use
their configuration section as an example but not name names.
Closes#228
Exit non-zero if something goes wrong during a run
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
See merge request !142
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
Actually remove enabled extensions from ignore list
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
cc @warsaw
See merge request !138
Add a release note to 3.0.0 about --exclude
When we rewrote Flake8 for 3.0, we unintentionally stopped forcibly
excluding some patterns regardless of what the user specified. This note
is added after the fact to make it easier for users to determine the
cause of any backwards incompatibility they might notice.
Closes#250
See merge request !139
When we rewrote Flake8 for 3.0, we unintentionally stopped forcibly
excluding some patterns regardless of what the user specified. This note
is added after the fact to make it easier for users to determine the
cause of any backwards incompatibility they might notice.
Closes#250
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
