`ruff.path` should be scoped to a window instead of resource
dhruvmanila opened this issue · 5 comments
The ruff.path config is scoped to a "resource" which means that in a multi-root workspace, one can configure this setting on a per-directory basis.
This was ok with ruff-lsp because it would use this executable for every invocation of linting / formatting. But, with the native server, it's only used to start the server which would happen on a workspace level.
This might be a breaking change for users who've configured ruff.path for each folder in a single workspace.
We should change this when we deprecate ruff-lsp.
But, it seems that you can have different virtual environments for each folder in a workspace. This means one cannot configure to use different Ruff version for each folder in a workspace. For this to even be supported, it'll require us to start different server instance for individual folders in a workspace.
Currently, ruff-vscode seems doesn't recognize the virtual environment in a multi-root workspace environment. The vscode shows a python virtual environment is activated, but ruff-vscode still says "Python interpreter missing".
@kkpattern can you say more about your issue and how does that relate to this one? Are all workspaces in the multi-root workspace related to Python or are there any that are of other language?
I created a demo repo for this: https://github.com/kkpattern/ruff-vscode-multi-root. I have two different projects in this repository, each with a different Python virtual environment. With the multi-root workspace feature, when editing project1/main.py and project2/main.py, the corresponding .venv1 and .venv2 are activated accordingly. But the ruff-vscode seems not to recognize the virtual environments. According to the log, it still uses the system Python interpreter.
I think that's probably unrelated to the issue here and might be another issue. Looking at the repository, the first folder in the workspace seems to be the root folder and it could be that the root folder doesn't have a corresponding Python interpreter selected in VS Code. I'm not sure, I might need more information to understand what's happening here.