microsoft/vscode-black-formatter

Multi-root workspaces require all folders to a valid python interpreter

geertj opened this issue · 1 comments

This adds additional context to issue #370 by another user which was closed due to lack of response. Since it appears not possible to re-open that ticket I'm adding a new one here.

In a multi-root workspace, it appears that the black server will not start up unless all folders have a valid Python interpreter. The suggested solution, to configure the same python in all folders, is not feasible for us. I wanted to add some context about our use case to explain why.

We use an older version of Linux as our primary development desktop (Amazon Linux 2). This version provides Python 2.7 and 3.7 by default. The minimum Python version for Black is 3.8. This is not a problem because in our setup, build tools are normally provided by our build system instead of the host OS. Packages that use Python configure the interpreter path to point to a wrapper in the local folder, which at runtime asks the build system for the actual Python location, and then executes that with the provided arguments. This has been working well for Pylance.

Why can't we configure all packages to work this way? Our build system contains a very large number of packages, and many of them are not using Python. These packages come together multi-root workspaces managed by our build tool, which is the primary location where developers develop. It is common to end up with workspaces containing packages that use Python and packages that don't. In such a case, the black extension falls back to the system Python for the latter packages, which does not meet the minimum version requirements, and is therefore preventing the black server from starting up.

EDIT: the ticket also suggested to use an "entire workspace" python version to set the Python version for all folders. While this is possible, the workspace-level configuration is not checked into source control. Therefore this adds friction for our developers that would need to edit this file manually for every workspace that they create.

@geertj We are working on a potential fix that should make this easier. Meanwhile, you can pin the version of the extension to use older version which supported 3.7.