263 | 266 | traceLog(`Python extension loading`); | |
264 | 267 | await initializePython(context.subscriptions); | |
265 | 268 | traceLog(`Python extension loaded`); |
This was a bug that would hang the extension when ruff.interpreter
is provided and the workspace is trusted. We would never call the runServer
in that case.
Before that commit, the extension would just move ahead and use the interpreter from the Python extension but now we explicitly stop moving ahead if it fails to resolve the environment corresponding to the interpreter.
Do we need to fall back to the interpreter from the Python extension?
Do we need to fall back to the interpreter from the Python extension?
We do fall back to that, it's just moved to settings.ts
when we get the workspace settings: https://github.com/astral-sh/ruff-vscode/pull/553/files#diff-3a5b47a3d2e56af22ee3eeb11a7ac02b69ac7b6bf52f9b48a870acd00da9f39a (getInterpreterDetails
)
Login to write a write a comment.
Summary
This PR updates the scope of
ruff.interpreter
setting fromwindow
toresource
in order to resolve the variables such as${workspaceFolder}
if present.In #551, what happens is that the Python extension fails to resolve the environment corresponding to that interpreter which causes the hang. The bug present in #551 was there for a very long time but it got visible because of e665ec7. Before that commit, the extension would just move ahead and use the interpreter from the Python extension but now we explicitly stop moving ahead if it fails to resolve the environment corresponding to the interpreter.
For reference, the
vscode-black-formatter
extension also updated the scope ofruff.interpreter
to beresource
in microsoft/vscode-black-formatter@5f2fc61.fixes: #551
Test Plan
Relative paths are unresolved
Logs:
Preview for the status bar:
Using VS Code specific variables
Logs: