On 1/13/22 2:20 PM, Ian Stapleton Cordasco wrote:
No this means that what you specify on the CLI will override whatever is in the configuration file. You can specify `--extend-select` on the CLI as well. Think of it like this:
There's a default list of ignores and select so you have some code that looks vaguely like:
select = ["E", "F", "W", "C"] ignore = [...]
Then when you specify extend-select we do
Whereas if you use select in your config file we're doing
select = user_specified_select # cli or config
So if you have extend-select in your config, and then specify --select on the CLI, we'll still follow that algorithm.
Right, so it is what I thought, sorry if it was not clear.
Though related to that, does flake8 only apply the defaults, one config file, and the CLI, or can multiple config files get merged? And does only the "last" extend-select (or others) get applied, or do all of them from all sources get combined?
- is `--select ''` the proper way to deselect everything?
As in you only want to report the things you've selected? Yes.
Mostly as in "I want to ensure only the things which are extend-selected by the configuration file apply"
- is there a way to make exclusions error-specific, or is an other workaround necessary to add large sections of the project to exclusions for the CI, but not prevent linting for people?
I don't know what you mean. I'm going to take a guess though,
You want to ignore errors from specific files? There's per-file-ignores you can specify in your config (or on the CLI) to do just that. That will affect everyone though if you put it in the config, so changing how you run flake8 for CI would mean needing to specify that.
It's a bit more complicated than that, basically we're trying to ramp up the strictness, but some of the checks are only "fixed" on a subset of the project. So I wanted to know if there's a way to say e.g. "check E on the entire repository but check W only on "core/", aside from having multiple configurations and running flake8 multiple times with different configurations (or, alternatively, post-processing the output).
Also, it's worth thinking about the fact that you can tell Flake8 which config file to read, so you _could_ tell it to read a different file for CI
Yeah, but the goal was to ensure the CI's stuff would apply both locally and on CI, but the local configuration would still apply (e.g. if a user wants to have more restrictions for their personal coding).