Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
geertj opened this issue Mar 13, 2024 · 1 comment
Open
Labels
bug Issue identified by VS Code Team member as probable bug needs investigation

Comments

@geertj
Copy link

geertj commented Mar 13, 2024

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.

@github-actions github-actions bot added the triage-needed Issue is not triaged. label Mar 13, 2024
@karthiknadig karthiknadig self-assigned this Mar 13, 2024
@karthiknadig
Copy link
Member

@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.

@karthiknadig karthiknadig removed their assignment Mar 29, 2024
@karthiknadig karthiknadig added bug Issue identified by VS Code Team member as probable bug needs investigation and removed triage-needed Issue is not triaged. labels Mar 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue identified by VS Code Team member as probable bug needs investigation
Projects
None yet
Development

No branches or pull requests

2 participants