Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to show (some) ignored codes but don't actually fail #515

Closed
asottile opened this issue Apr 3, 2021 · 9 comments
Closed

Option to show (some) ignored codes but don't actually fail #515

asottile opened this issue Apr 3, 2021 · 9 comments

Comments

@asottile
Copy link
Member

asottile commented Apr 3, 2021

In GitLab by @xZise on Jul 6, 2016, 06:16

Would it be possible to add a feature to have a third kind of “ignore-state” where it ignores that it happened but it actually shows the error?

So that there are error codes which are shown and will fail the run, then some which are shown but won't fail the run and then some which aren't shown and won't cause a failure.

This feature isn't really that important, but it would help to “combat” “soon-to-be unignored” errors as they will appear but won't cause a failure so you don't need to run Flake8 again with these errors “unignored”.

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @sigmavirus24 on Jul 6, 2016, 06:42

So this sounds like you want a confidence system that plugins can use to report things, e.g.,

  • High - Report this and cause things to fail
  • Medium - Report this but don't cause things to fail, could be a false positive
  • Low - Neither report this nor cause things to fail

Everything in --ignore would be forced to have Low priority.

This is very much a pylint feature more than a flake8 one in my mind. This could be a good feature for Flake8 4.

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @zoidyzoidzoid on Jul 6, 2016, 08:59

Some sniffers/linters have warnings and errors which is sort of similar. Some error codes could be downgraded to warnings?

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @sigmavirus24 on Jul 7, 2016, 06:06

@zoidbergwill it's not that simple. PyCodestyle (formerly pep8) used E and W prefixes for their violation/error codes to indicate "Error" and "Warning" and so other thing use other letters: "C" for McCabe complexity, "I" for Import ordering, etc.

I think a confidence system would be less confusing for users than "errors" and "warnings".

I hope that makes sense.

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @zoidyzoidzoid on Jul 7, 2016, 14:32

100%. I forgot that the PyCodestyle error codes include ones for warnings. My bad.

The confidence system sounds like a better idea, with less ambiguity.

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @sigmavirus24 on Jul 7, 2016, 14:36

No worries! I just wanted to make sure we were all on the same page here. :)

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @sigmavirus24 on Nov 12, 2016, 11:42

So, here's how you can do this today:

flake8 --exit-zero --select [...] ...

This allows you to enable those violations while not failing. It'd be a separate run, but you can at least do this today.

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @sigmavirus24 on Oct 20, 2018, 10:40

#332 is a better option

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @sigmavirus24 on Oct 20, 2018, 10:40

closed

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @asottile on Oct 2, 2020, 16:38

changed the description

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant