Add Command to enable/disable linting

[alex-nl]

The built-in, deprecated linter has the useful Command Palette command "Python: Enable/Disable Linting". I'm finding this very useful as I work in a code-base that's slowly being migrated to a new code style.

The workaround is to disable/re-enable the whole extension and restart VS Code which is significantly more cumbersome. Also, by providing a Command, that command can be keybound, called from other extensions, etc.

Thank you for considering this feature request!

[luabud]

Hi @alex-nl! Chatting with the team we decided not to go forward with this idea given this would be redundant. You have a good point that having to reload VS Code can be cumbersome, but our expectation is that folks wouldn't find themselves wanting to flip through enabling/disabling linters often. If that's not the case for you, I'd love to get a better understanding on your use case.

There are a couple of alternatives here that might be interesting:

• Always keep this extension disabled, and only enable it by workspace-basis, given VS Code does not require a reload to enable extensions:

• Set up Profiles with and without this extension, and then switch among them when you don't want to use the extension: https://code.visualstudio.com/docs/editor/profiles

[noirbizarre]

This is kind of regression, as it was possible to toggle linters by directory/project in multiroot workspaces when they were bundled with Python VSCode. This makes them unusable for multiroot workspaces as you have no guarantee that all projects are using the same linter (and surprise, these are my cases).

In my case, I have multiple multiroot workspaces, most of them are mixing projects using Ruff, Flake8 and Pylint as linters and result in multiple lintings with contradictory false negatives because project using one linter do not define rules for others resulting in non-expected linters flooding with false negatives (e.g. Flake8 line length is set to 80 if you are using ruff and have defined this line length in ruff settings only). Plus, the fact that all enabled linters run for all directories/projects, highly loads the CPU and RAM for nothing.

So for the moment, until we have a way to toggle linters by directory in multiroot workspaces, I removed the flake8 and pylint extension, only have ruff one installed and I manually lint from the shell for flake8, which is kind of defeating the linters' integration 😓

I think a setting is way better than a command because settings can be written by external tools while the command requires to have VSCode running and is only available inside VSCode (and in my case, I have written a tool which was automatically providing those settings and was working just fine with the built-in linter settings and which cannot work anymore with this new behavior)

Note: toggle the extension could be an acceptable alternative if and only if:

• we can do it at directory level (currently only workspace level)
• we don't have to reload VSCode on toggle (which is currently the case when you want to disable it)
• we can specify it in JSON settings (as it was the case before), aka. .code-workspace file for workspace level or in .vscode/settings.json for directory/project level (not the case currently, extension have to be manually enabled for each workspace)

Note: same apply for formatters, some projects require black formatting, some other not. Having VSCode formatting projects that shouldn't be just to have formatting on those where it is expected is a bit annoying.

[b4stien]

I could not agree more on @noirbizarre's perfect write-up of the situation, multiroot workspace have been severely crippled by this change.

At my company we're migrating from flake8 to ruff, one project (hence one folder) at a time. It is no longer possible to have those projects under the same workspace (what have been our worflow for the past 3+ years).

[thomasbbrunner]

Cannot agree more with the comments above. And I have to disagree with @luabud statement of "our expectation is that folks wouldn't find themselves wanting to flip through enabling/disabling linters often".

This is a regression in capabilities when compared to the previous extension. Why remove previously available features?

Also, for those with a keyboard-centric workflow, using the mouse to go to the extensions menu and right clicking to disable the extension feels sluggish when compared to using the command palette.

[ThiefMaster]

Yes, please bring back at least a setting for it. I have both the flake8 and ruff extensions installed. Some of my projects use flake8, some use ruff, some use both (for now). The ability to configure which linter to (not) use seems like a no-brainer...

[karthiknadig]

Added a setting flake.enabled via PR https://github.com/microsoft/vscode-flake8/pull/268

[b4stien]

Thanks a lot for this change, do you think you could cut a pre-release to make it available for pre-testing?

[karthiknadig]

This is in 2023.13.10582022 build.