You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.
The text was updated successfully, but these errors were encountered: