Need a way to find tools (linters, formatters) via PATH

Unless I’m misunderstanding something, if I enable a linter like flake8, VS Code expects it to be installed in my Python environment (and specifically, if I don’t set Flake8Path in my settings, that’s where the extension will look).

I don’t install tools like flake8 or black under my project - rather, I have a separate installation using a tool-specific virtualenv (essentially using a mechanism like pipx to manage my tools, although I actually use a custom solution). So I have flake8 and black commands on my PATH.

If I want to use my globally-installed tools, I appear to have to specify the exact path to them in my VS Code settings - which is not ideal, as the whole point of installing them centrally is that no other tools have to know where they are located, they can just access them via PATH. As things stand, if I move my tool directory, my VS Code config breaks.

Please provide a way to tell VS Code to search PATH for tool locations. Even if it’s not the default, and I need to check something that says “search for flake8 on PATH”, etc, that would at least allow me to make my VS Code configuration portable.

[TBBle]

I’ve just bounced off this issue, and for me, part of the problem is that the error message shown is not clear.

If python.formatting.blackPath is unset, black is discovered/validated by

<Whateveryourcurrentinterpreter> -c "import black"

and the Python log shows

Error: Module 'black' not installed.

but the popup says “Formatter black is not installed. Install?”. If that said “Module black is not installed in current Python environment” then it would have pointed me in the more-correct direction. As it stands, I can say “Yes”, let VSCode change my current Python environment, and then if I switch environments, it will want to install it again, even though the VSCode-installed black.exe is still in my path, which is mystifying behaviour if you assume “format with black” means “black.exe <args>”.

Once I set python.formatting.blackPath to ~\.local\bin\black.exe (for my pipx-installed copy of black) then no module discovery is attempted, and it happily calls that executable.

Sadly, the logic that decides if the name is a module or an executable is based on whether it contains a path, making it impossible to trigger the “executable path” with a bare executable name.

My ideal behaviour is that by default it tries <interpreter> -m black (for when I’m working on a project with a venv, e.g., managed by Poetry, and have a specifically-blessed version of black as part of the project definition) and if not present, fell back to executing black as a binary via the PATH, for when I’m just randomly pulling python scripts off the Internet to run with py.

Then I wouldn’t need custom settings to make arbitrary Python files work, nor would I need to override that custom setting because <interpreter> -m black is the correct thing in places where I do have a workspace-local .vscode, so I need to override the user-wide pathed black setting.

[brettcannon]

To give some history, we actually originally searched PATH for tools like flake8 and black, but the amount of bug reports we got from people who weren’t sophisticated enough to have their PATH set appropriately to have the tool on PATH (or at least the version they wanted at the front), we decided to change to our -m approach + explicit paths.

If someone wanted to work on an opt-in solution to also search PATH we would be open to discussing on how to implement it.