| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
found via `pre-commit try-repo https://github.com/codespell-project/codespell --all-files`
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Allow for including options from parent `argparse.ArgumentParser`
objects in preparation of splitting out the handling of preliminary
options from the `OptionManager`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling `ArgumentParser.parse_args()` with the `namespace`
argument, command-line options are just added to the namespace without
going through any of the argument parsing and type conversion logic
(e.g., the `type` keyword argument of `ArgumentParser.add_argument()`).
In other words, it is assumed that a namespace is well-formed from a
previous invocation of `ArgumentParser.parse_args()`.
The `values` parameter is intended to be values already-provided from
configuration files. To take advantage of the logic defined by
`ArgumentParser.add_argument()`, utilize
`ArgumentParser.set_defaults()` instead.
|
| |
|
|
|
| |
Note that the `assert` is necessary to "cast" `self.parser` since it is
specified as a `Union`.
|
| |
|
|
|
| |
Note that type casting is necessary given that `self.parser` is
annotated as a `Union`.
|
| |
|
|
|
| |
The `values` parameter is not utilized anywhere and can be safely
removed.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the contract has narrowed for `utils.normalize_paths()`
and `utils.parse_comma_separated_list()`, `Option.normalize()` must
handle when the option value is either a singular value or a sequence
(i.e., `list`) of values.
The paths where `Option.normalize()` is called are:
1. options/config.py: `MergedConfigParser.parse_*_config()`
There are 3 paths wehre eventually `_normalize_value()` is called.
2. options/manager.py: `OptionManager.parse_args()`
For (1), values are coming from the `configparser` module. For (2),
values are coming from `optparse.OptionParser`.
Rudimentary investigation seems to implicate that
`optparse.OptionParser.parse_args()` always returns values in a `list`
because it accumulates values. However, for `configparser`, the values
are a string due to the key-value nature of the INI format.
Given that `Option.normalize()` is the convergence point where
normalization of an option occurs, it is acceptable for the method to
also handle the parsing comma-separated values and path normalization by
the option value's type.
|
| | |
|
| |
|
|
|
|
|
| |
This helps normalize_from_setuptools, to handle all
optparse's standard-option-types.
Fixes #452
|
| |
|
|
|
| |
Instead of just using Flake8 and pylint to keep Flake8 clean, let's also
use black to make it less manual for clean-up.
|
| |
|
|
|
| |
This allows us to report whether or not a plugin is local when users
provide `flake8 --bug-report` output.
|
| | |
|
| |
|
|
|
|
|
|
| |
By ordering the plugins, --version becomes reproducible so that it
continuously prints the same output (provided the plugins have not
changed).
Closes #297
|
| |
|
|
|
|
|
| |
When invoked it will print out JSON that has all of the debugging
information needed by the maintainers to diagnose or reproduce a bug.
Closes #207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, all testing was done from the directory in which the
configuration file lived, so this bug went unnoticed. However, if you
run Flake8 against its own source from a directory above, you would
notice that the patterns in the exclude config value in tox.ini were
ignored. This is because we (like any reasonable person) are using
relative paths. The path is relative, however, to the directory in
which the configuration file was located. So we keep track of which
directory that is and use that to normalize the paths in the config
file.
Yes, there is an unrelated change to our tox.ini in this commit as
well. ;-)
Closes #194
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
When flake8's config is in setup.cfg, setuptools attempts to set those
options on the command instance. If they don't exist, it fails early
complaining that a specific option does not exist.
This adds this back and does it better than the Flake8 2.x version.
Closes #163
|
| |
|
|
|
|
|
|
|
|
|
| |
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 the --select was only ever populated to E,F,W,C and so
plugins would not be reported when not off-by-default. This adds a
tiny shim so that we enable plugins that are not off-by-default and
:x
:x
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
This is an emerging best practice and there is little reason to not
follow it
|
