Flake8: how to compose project and personal configurations?
Hello, Sorry for the bother but I had a question about balancing personal and project uses of flake8: on a project we're trying to progressively introduce flake8 (so enabling a subset of all checks on a subset of all files). We tried adding a config doing via "select" and "ignore" in the existing setup.cfg, however this turned out to break a lot of people's linting, as their editor simply ran flake8 in the default configuration and they used that for their contributions (even though it was not checked project-wide). Looking further into this, it looks like recent versions of flake8 have "extend-ignore" and "extend-select" to avoid breaking things locally, however there are a few issues I don't know how to fix, or whose semantics is not clear: - according to the documentation, CLI values have the highest priority, but how does that work with select versus extend-select? Is `--select` used as the baseline then `extend-select` from the configuration files gets added to that? - is `--select ''` the proper way to deselect everything? - 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? Regards, Xavier
On Wed, Jan 12, 2022 at 9:33 AM Xavier Morel via code-quality < code-quality@python.org> wrote:
Hello,
Sorry for the bother but I had a question about balancing personal and project uses of flake8: on a project we're trying to progressively introduce flake8 (so enabling a subset of all checks on a subset of all files).
We tried adding a config doing via "select" and "ignore" in the existing setup.cfg, however this turned out to break a lot of people's linting, as their editor simply ran flake8 in the default configuration and they used that for their contributions (even though it was not checked project-wide).
Looking further into this, it looks like recent versions of flake8 have "extend-ignore" and "extend-select" to avoid breaking things locally, however there are a few issues I don't know how to fix, or whose semantics is not clear:
- according to the documentation, CLI values have the highest priority, but how does that work with select versus extend-select? Is `--select` used as the baseline then `extend-select` from the configuration files gets added to that?
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 select.append(extend_select) 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.
- is `--select ''` the proper way to deselect everything?
As in you only want to report the things you've selected? Yes.
- 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. 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
Regards,
Xavier _______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: graffatcolmingov@gmail.com
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
select.append(extend_select)
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).
On Thu, Jan 13, 2022 at 8:07 AM Xavier Morel via code-quality < code-quality@python.org> wrote:
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
select.append(extend_select)
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?
So for Flake8 4.0+ the order of precedence is: CLI - highest precedence Config files - flattened into one set of options Defaults
- 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"
So if you only want to see a subset of errors, --select is correct. That will not play well with what you seem to be trying to achieve though which is some mishmash of users using their own styles and having a project style simultaneously that aren't quite the same.
- 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).
No, there isn't. There is a way of selectively ignoring things, but not selectively selecting things. People most often want to ignore things rather than only select errors in a code-base and so there's no point in implementing every way of doing something given the massive complexity already present.
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).
If a user wants Flake8 to do something differently, they should be specifying it via `--config` not having you try and juggle a project style that's different from their own personal style. You're seeking a technical solution to unreasonable requests being made by people of your project. Set boundaries. Put your foot down. One style, that's progressively improving. Better yet, use an auto-formatter and get to that end state faster.
You're seeking a technical solution to unreasonable requests being made by people of your project. Set boundaries. Put your foot down.
I was about to answer something like this: the team has to follow. As all changes, though, this goes with some struggle. Stuff that may help resolving that struggle: * help them configure their beloved editors * help them avoid mistakenly committing: https://pre-commit.com/ helped us a lot * stick to an agreed-upon version of flake8 Kind regards Kristoffel
Not exactly an answer to the question you posed, but I found myself in a similar situation not long ago where I wanted to add flake8 to CI for a large codebase that had many violations to the rules we wanted to enforce. I found it useful to automatically add a #noqa to the preexisting violations before turning flake8 on so that no new violations could be introduced while the others were handled or ignored. I have a small script which does that in-place if you think that would be helpful (https://gist.github.com/AlexRiina/d8dfd39d2c6c4b121c8776070a2272dc) which you can run like flake8 > flake8_violations python noqaer.py (standard warning that running random scripts on your codebase without understanding what they do is a bad idea and that this is provided without warranty that it'll work and not mess up your codebase) On Fri, Jan 14, 2022, 8:18 AM Kristoffel Pirard <kristoffel.pirard@gmail.com> wrote:
You're seeking a technical solution to unreasonable requests being made by people of your project. Set boundaries. Put your foot down.
I was about to answer something like this: the team has to follow. As all changes, though, this goes with some struggle.
Stuff that may help resolving that struggle:
* help them configure their beloved editors * help them avoid mistakenly committing: https://pre-commit.com/ helped us a lot * stick to an agreed-upon version of flake8
Kind regards Kristoffel _______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: alex.riina@gmail.com
participants (4)
-
Alex Riina -
Ian Stapleton Cordasco -
Kristoffel Pirard -
Xavier Morel