| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This has been a huge support burden for us. I seriously considered doing
this in 3.0 but caved to a vocal minority and the desire to keep as much
backwards compatibility as possible. At this point, however, I'm done
witnessing the abuse Anthony has to suffer over this and I'm done with
the undue hostility that people who don't bother to read the docs
display. Hopefully, this eases that a bit.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Flake8 3.0 we've had the ability for plugins to use
`extend_default_ignore` to register codes they want disabled by default.
This, however, was a permanent disabling unfortunately. Our code didn't
have a way of understanding that this new set of `ignore` codes was
actually the 'default' set for that run. Much like the
extended_select_list, we now attach extended_ignore_list to be able to
confidently determine if the ignore we get in the DecisionEngine is
actually the Default Ignore list and what plugins what us to ignore by
default.
Refs https://github.com/PyCQA/pep8-naming/pull/157
|
| |\
| |
| | |
Typo fix
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
found via `pre-commit try-repo https://github.com/codespell-project/codespell --all-files`
|
| | |
|
| |
|
|
|
|
|
|
| |
Paths specified in configuration files should be relative to the
directory where the configuration file resides. Formerly, paths were
normalized relative to the current working directory where `flake8` was
invoked. The former behavior was not expected, especially for directory
structures with subprojects each having their own configuration.
|
| |
|
|
|
|
| |
This sets things up to support normalizing paths relative to parent
directories specified by callers who have more context for determining
what paths should be relative to.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Preemptively determine the path of the user configuration file during
the construction of the `ConfigFileFinder` object. The user
configuration path will always be the same, regardless of when it gets
obtained by a run of `flake8`.
This isolates the logic of determining the user configuration path into
a static helper method to be called to set the `.user_config_file`
attribute. The helper method leverages `utils.is_windows()`, instead of
reimplementing the check, and decomposes clearly the directory name and
the base name to construct the path with a single `return` path.
Additionally, this avoids reconstructing the path on demand of obtaining
the user configuration file path.
|
| |
|
|
|
|
| |
Remove the checks to see if a configuration file has already been seen
and parsed. These checks aren't necessary because the entire run of
`flake8` calls these methods *only* once per configuration provided.
|
| | |
|
| |
|
|
|
| |
This simplifies the number of required parameters needed for the
`ConfigFileFinder` object throughout the various tests.
|
| |
|
|
|
|
| |
Now that `ConfigFileFinder.config_file` attribute is used everywhere and
is constructed from the `--config` CLI option, the now unused
`cli_config` parameters can be safely removed.
|
| |
|
|
|
|
|
|
| |
Now that the `ConfigFileFinder` has the `.config_file` attribute, switch
the relevant code paths to utilize this public attribute.
Tests have been updated to either construct `ConfigFileFinder` or mock
the object appropriately.
|
| |
|
|
|
|
|
|
|
| |
The `--config` flag is passed into `MergedConfigParser.parse()` and the
module-level function `config.get_local_plugins()`. Since both of these
places utilize the `ConfigFileFinder` object and the configuration file
override pertains to how configuration behaves, this incremental change
directly associates the `ConfigFileFinder` and the configuration file
override.
|
| |
|
|
|
|
|
| |
These attributes are only needed within the
`.generate_possible_local_files()` method. Therefore, just obtain the
current working directory at the beginning of the method and reduce the
lifetime state of the `ConfigFileFinder` object.
|
| |
|
|
|
|
| |
Now that `ConfigFileFinder.ignore_config_files` attribute is used
everywhere and is constructed from the `--isolated` CLI option, the now
unused `isolated` parameters can be safely removed.
|
| |
|
|
|
|
|
|
|
| |
Now that the `ConfigFileFinder` has the `.ignore_config_files`
attribute, switch the relevant code paths to utilize this public
attribute.
Tests have been updated to either construct `ConfigFileFinder` or mock
the object appropriately.
|
| |
|
|
|
|
|
|
|
| |
The `--isolated` flag is passed into `MergedConfigParser.parse()` and
the module-level function `config.get_local_plugins()`. Since both of
these places utilize the `ConfigFileFinder` object and isolation
pertains to how the `ConfigFileFinder` should behave with respect to
isolation, this incremental change more directly associates the
`ConfigFileFinder` and configuration file isolate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies `._read_config()` by removing a conditional branch in
the situation where it is called with one file to process. Now the
contract accepts any number of arguments of the same type.
Where callers invoke `._read_config()` with a `Sequence`, the call site
has been changed to unpack arguments (i.e., `*`).
The tests in `test_merged_config_parser.py` needed to return a string
for the user configuration path instead of an empty list since
`ConfigFileFinder.user_config_file()` returns a string.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression introduced in !346 to ensure that `--config` and
`--isolated` are recognized in `aggregate_options()`.
The regression manifested because `aggregate_options()` was relying on
re-parsing `argv` to obtain the option values. However, !346 changed
the preliminary parsing logic to only parse and "eat" what is necessary
and forward along the options needed before all the configuration was
loaded. This code path was overlooked because the tests in
`test_aggregator()` were passing but the call from the `Application`
object would never have these options in the remaining `argv` list to be
passed long.
|
| |
|
|
|
|
| |
The `values` parameter is safe to remove since it is not provided as an
argument by any callers and the remaining arguments are guaranteed to
always be provided by all callers.
|
| |
|
|
|
|
| |
Allow for including options from parent `argparse.ArgumentParser`
objects in preparation of splitting out the handling of preliminary
options from the `OptionManager`.
|
| |
|
|
|
|
|
|
| |
Now that `args` parameters is not being used, it is safe to remove from
the constructor signature.
Further work is required to evaluate and clean-up tearing out the
threading-through of `args` from various callers and tests.
|
| |
|
|
|
|
| |
This is the initial incision to only search for configuration relative
to the current working directory where `flake8` is invoked. This brings
configuration file detection closer to other CLI-like programs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
`OptionManager.parse_known_args()` is guaranteed to return a list of
remaining argument strings.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Move the path normalization for extra configuration file paths down into
the main `config` module where other path normalization occurs.
This also guarantees that the call to `utils.normalize_paths()` is given
a sequence, instead of a potential `None` value.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Add support for optparse's 'float' and 'complex' types.
Closes #452
See merge request pycqa/flake8!261
|
| | |
| |
| |
| |
| |
| |
| | |
This helps normalize_from_setuptools, to handle all
optparse's standard-option-types.
Fixes #452
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Support more syntaxes in per-file-ignores
Closes #471
See merge request pycqa/flake8!281
|
| | | | |
|
| |/ / |
|
