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.
Simplify the initialization code path by invoking
`config.ConfigFileFinder` directly instead of the extra hop by calling
the static class-level `Application.make_config_finder()` method.
The `.local_plugins` attribute can be removed from the `Application`
since the usage of the `LocalPlugins` object is isolated to the
`.find_plugins()` method.
This change removes the `.config_finder` object from the `Application`.
Since the configuration finder is only needed during initialization, we
constrain the finder to be returned and passed to other methods
necessary for initialization.
Remove the checks to see an object was already created before creating
or obtaining it. This is not necessary as each entire run of `flake8`
calls these methods *only* once.
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.
This commit simplifies and updates the method for handling the creation
of the configuration file finder. The main takeaways are:
- Renaming the parameter (i.e., `extra_config_files`) to be a noun to
better describe the input versus what the option name was called.
- Refreshed the docstring to align with changes from previous commits
and this one.
- Remove the check to see if it a configuration file finder was already
created. This is not necessary as each entire run of a `flake8` calls
this method once. When the programmatic API is provided,
configuration would be provided 'in-code' and not rely upon external
files/resources.
- Use directly the program name from the `Application`, itself since
this is the authoritative source for defining it.
Now that `parse_preliminary_options_and_args()` ignores unknown options
and arguments, forward the remaining unknown arguments to the main CLI
and configuration method to be consumed. This prevents re-parsing the
entire `argv` list again by forwarding the remaining arguments left to
be consumed.
Positional arguments aren't necessary for determining where to
load configuration anymore and is safe to keep both options and
arguments to be forwarded for later parsing after configuration is
loaded.
Now that preliminary options are registered with the preliminary parser
on the `Application`, leverage that for parsing known options.
This important change removes the `Application.option_manager` from
being responsible for pre-configuration parsing and the workarounds
needed in the `Application.parse_preliminary_options_and_args()` to
account for the fact that `Application.option_manager` was aware of
*all* options, not just the options necessary for pre-configuration
loading. A following commit will address removing these workarounds.
We introduce a new `ArgumentParser` for registering the preliminary
options to be inherited by the `Application.option_manager`. The next
step will be to use the `Application.prelim_arg_parser` for parsing and
handling preliminary options and arguments.
Note that we prevent the preliminary parser from handling `-h/--help`
and defer to that to the primary parser.
Allow for including options from parent `argparse.ArgumentParser`
objects in preparation of splitting out the handling of preliminary
options from the `OptionManager`.
The `ConfigFileFinder` doesn't utilize the preliminary arguments (i.e.,
the file names) anymore for computing the starting path for the
configuration file search.
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.
