| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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 `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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This change makes `Application.make_config_finder` to be side-effect
free where it its return value is only determined by its input values.
|
| |
|
|
|
|
| |
Positional arguments are not used nor parsed for pre-configuration
loading. Thus, renaming the method and updating the docstrings
appropriately.
|
| |
|
|
|
| |
This resets the `black` formatting baseline so it doesn't get picked up
in future commits.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The `ConfigFileFinder` doesn't utilize the preliminary arguments (i.e.,
the file names) anymore for computing the starting path for the
configuration file search.
|
| |
|
|
|
|
| |
The configuration file and boolean to ignore configuration files can be
threaded through now that `.parse_preliminary_options_and_args()`
returns options and arguments.
|
| |
|
|
|
|
| |
Now that `.parse_preliminary_options_and_args()` returns options and
arguments, the boolean for appending configuration and the arguments can
be threaded through to the creation of the `ConfigFileFinder`.
|
| |
|
|
|
|
| |
The verbosity and output file options can be obtained from options
returned by `.parse_preliminary_options_and_args()`, instead of state
from the `Application` object.
|
| | |
|
| | |
|
| |
|
|
|
| |
Instead of just using Flake8 and pylint to keep Flake8 clean, let's also
use black to make it less manual for clean-up.
|
| |
|
|
| |
Closes #357
|
| | |
|
| |
|
|
| |
style_guide/formatter.
|
| | |
|
| |
|
|
|
|
|
| |
For our Legacy API users, StyleGuide.init_report should reset the
formatter attribute before calling Application.make_formatter().
Closes #200
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If users do `from flake8.api.legacy import *` we only want them to get
get_style_guide imported. The other classes are not meant to be created
by users.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to initialize part of the Application so we can set options
passed by the user, but we also want to delay making things, e.g.,
- Formatter
- Style Guide
- etc.
Until we have the options solidified so we don't have to do annoying
things.
|
| | |
|
| | |
|
| |
|
|
|
| |
This does not handle setting custom options via the parameters to
get_style_guide.
|
| | |
|
|
|
This is an emerging best practice and there is little reason to not
follow it
|