Support restricting file-level noq (# flake8: noqa) to certain errors

[asottile]

In GitLab by @diekhans on Jan 12, 2018, 16:11

Please describe how you installed Flake8

$ pip install lake8

*Please provide the exact, unmodified output of `flake8 --bug-report`*
{
  "dependencies": [
    {
      "dependency": "setuptools",
      "version": "28.8.0"
    }
  ],
  "platform": {
    "python_implementation": "CPython",
    "python_version": "3.6.2",
    "system": "Linux"
  },
 "plugins": [                                                                  
    {                                                                           
      "is_local": false,                                                        
      "plugin": "mccabe",                                                       
      "version": "0.6.1"                                                        
    },                                                                          
    {                                                                           
      "is_local": false,                                                        
      "plugin": "pycodestyle",                                                  
      "version": "2.3.1"                                                        
    },
    {
      "is_local": false,
      "plugin": "pyflakes",
      "version": "1.6.0"
    }
  ],
  "version": "3.5.0"
}     


*Please describe the problem or feature*

It would be useful to be able to disable specific categories or errors for an entire
file in an file level noqa.  Something like:

flake8: noqa: E731,E123

would do the trick with minimal syntax additions


*If this is a bug report, please explain with examples (and example code) what you expected to happen and what actually happened.*

[asottile]

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

There is no such support for file-level ignores

[asottile]

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

closed

[asottile]

In GitLab by @diekhans on Oct 20, 2018, 14:28

This is an enhancement request. Hence, "no such support for file-level ignores" doesn't address the ticket. That is the requested change.

Maybe there are good reasons for not doing it, but there is support for its usefulness.

[asottile]

In GitLab by @diekhans on Oct 21, 2018, 11:40

reopened as enhancement request

[asottile]

In GitLab by @diekhans on Oct 21, 2018, 11:40

reopened

[asottile]

In GitLab by @asottile on Oct 21, 2018, 16:44

There's a plugin which takes an attempt at implementing this: flake8-per-file-ignores -- I think it makes sense to support this in flake8 directly given the demonstrated demand. I'll see what I can do about this (or if you want to attempt a PR that would be great!) :)

[asottile]

In GitLab by @sigmavirus24 on Oct 21, 2018, 17:01

There's already an accepted proposal to allow per-file ignores in config
files. I would prefer that as it centralizes the terrible

[asottile]

In GitLab by @asottile on Oct 21, 2018, 17:06

I assume you mean https://gitlab.com/pycqa/flake8/issues/156 (though that also mentions the # flake8: noqa XXX comment as well) -- in which case this can be closed as a duplicate

[asottile]

In GitLab by @sigmavirus24 on Oct 24, 2018, 08:49

#156 is about adding it to configuration files which is what I'm implementing.

Allowing it in #flake8: noqa is a recipe for someone checking a file into a team's source code with # flake8: noqa E,F,W so they don't have to worry about their code being linted. It's easier to miss. Having the configuration centrally located allows for auditing and should serve as a klaxon to a reviewer when someone checks in a file where they've totally disabled rules.

So in some ways this is a duplicate of #156 and in others it's a rejected feature. Feel free to chose your own view of the glass

[asottile]

In GitLab by @sigmavirus24 on Oct 24, 2018, 08:49

closed

[asottile]

In GitLab by @ssbarnea on Jan 26, 2020, 01:35

I find hard to understand the reasons for closing this as there is an already BFG that nukes all checks at file level: # flake8: noqa.

So basically the feature is refused because it could be used wrongly, when at the same time a much more dangerous option is the only workaround left to the users.

This also reminds me of another refused feature, the one that would allow use of the closest config file. So you could have different set of rules for different directories, something extremely useful when you try to improve checks on a big codebase. And yes, I know about calling tool multiple times in each directory, a recipe for failing to miss newly added files.

[asottile]

In GitLab by @blueyed on Jan 26, 2020, 05:26

@ssbarnea

the one that would allow use of the closest config file

A reference link might be good, but it is rather a bit offtopic anyway. Just wanted to mention that there are per-file-ignores by now (but be aware of https://gitlab.com/pycqa/flake8/issues/517 then).

[asottile]

In GitLab by @sigmavirus24 on Jan 26, 2020, 08:19

mentioned in commit f277610

[asottile]

In GitLab by @ssbarnea on Jan 26, 2020, 10:02

Thanks. I also created !410 to improve the docs.

[asottile]

In GitLab by @asottile on Feb 18, 2020, 08:07

mentioned in merge request !412

[imomaliev]

@asottile Hi. Could you help me find where https://gitlab.com/pycqa/flake8/issues/517 was moved after github migration. I see mentions of it in other issues like this one, but can't find what it's current issue id.

[asottile]

#693

[imomaliev]

@asottile Thank you)

[rob-miller]

I feel this should be re-opened as an enhancement request (again) because of the expanded use of VS Code as a development environment for Python (e.g., by ca. 75% of [a tiny number of of survey-responding] developers according to Wikipedia).

Specifically, I have the following use case:

• The majority of my development is submitted to an open source package hosted on Github, with specific requirements and hooks for pull requests. I'm happy with these, and they've made it so that my PRs now generally pass CI without issue.
• Often I develop test code (not for submission) within the development directory, or now for a separate project that I'm just starting up. I cut-and-paste lots of code from other sources and, because I am using the same VS Code configuration, my problem list is full of F401 'imported but unused' messages. I will eventually use these imports, or I will clean them up later, but for now it is difficult to see the real issues that I want flake8 to tell me about.
• I can't/shouldn't change the config file in the development directory because that's part of the public package, and I prefer not to customize it in the new project because that's separate from my code and easy to miss (it's not something I would commonly look at). For similar reasons I don't want to modify the flake8 command line in the VS Code configuration. This is admitedly a temporary situation, but it makes it difficult to use flake8 as a tool for development at this stage, and it instead generates 'noise' in my environment.
• Adding per-line noqa's or adding (in the F401 case) the imports to __all__ as suggested on stackoverflow ignores the point of trying to focus directly on development. If I have to modify each line to get around flake8 then I may as well fix the line - except that I actually want the issues at a later stage to remind me to either remove the reference or address something that is still missing.

I've tried to follow the discussion above despite the outdated links, and I appreciate what appears to be pasting in comments from relevant GitLab posts. The primary issue I can find with implementing this feature seems to be:

There's already an accepted proposal to allow per-file ignores in config files. I would prefer that as it centralizes the terrible

Allowing it in #flake8: noqa is a recipe for someone checking a file into a team's source code with # flake8: noqa E,F,W so they don't have to worry about their code being linted. It's easier to miss. Having the configuration centrally located allows for auditing and should serve as a klaxon to a reviewer when someone checks in a file where they've totally disabled rules.

It seems like this should be handled under a --disable-noqa type option (or with grep) at the review or CI level, and a developer that purposefully does this in a team environment is an egregious situation that is probably beyond flake8's remit.

My preference is to enable a useful feature for experienced developers instead of protecting everyone from hypothetical misuse by poor developers.

[asottile]

per-file-ignores is the intended mechanism for this -- also looks like the gitlab migration didn't bring over the locked status, annoying