Only activate language servers when running in virtual workspaces#17519
Conversation
a387c59 to
7540b23
Compare
7a2e5ef to
05520d4
Compare
05520d4 to
8079b3c
Compare
| protected getDocumentFilters(_workspaceFolder?: WorkspaceFolder): DocumentFilter[] { | ||
| return PYTHON; | ||
| return this.workspace.isVirtualWorkspace ? [{ language: PYTHON_LANGUAGE }] : PYTHON; | ||
| } |
There was a problem hiding this comment.
Support all virtual workspaces schemes.
|
For this, is there any reason to block interpreter access in virtual? I think it would be valid to have a local venv that you source type information from during the analysis; Pylance will fall back to calling |
|
Only reason is we wanted to start with the minimalistic features to make Pylance work 😄
I think Pylance still does have access to the current interpreter, we only don't allow the user to change it. The ideal solution would be to just activate "interpreter" component along with language servers, I'll see if I can do that in this PR. |
596e70e to
6221b0c
Compare
|
Done, please have a look again, thanks! |
|
LS stuff seems fine to me, but since I'm leaving (and will be gone for two weeks on vacation), I think it'd be best for someone else to give this a try too. |
|
Ping @karthiknadig |
…crosoft/vscode-python#17519) * Only activate Pylance when running in virtual workspaces * News entry * Trigger intelliSense analysis for all schemes of python code * Also support Jedi in virtual workspaces * Rebase with main * Oops * Only support known virtual workspace scheme * Look into all python schemes when in a virtual workspace * Fix some tests * Fix mistake * Do not register Jupyter hooks when using virtual workspaces * Nit * Only activate interpreter and language server component when in a virtual workspace * Make component id a mandatory field in extension activation services * Refactor * Use supported workspace types instead of component id * Fix lint * Code reviwes
Closes #17519