incorrect venv resolution with nested projects in a multi-root vscode workspace.

[strangemonad]

First off, thanks so much for this awesome work, moving along core improvements.

The issue is a little hard to describe so I've created a repro case repo. https://github.com/strangemonad/basedpyright-nested-workspace/tree/main it creates a minimal repro case with 2 projects in a multi root workspace repo.

• open the project.code-workspace workspace in vscode.
• open b/tests/test_greet.py and observe that even when the vscode python venvs are correctly configured, the import isn't resolved correctly.

I believe the root cause is when the LSP falls back onto resolving file imports using an interpreter, it seems to pick the first vscode workspace venv that matches the prefix. otherwise, the LSP instances look correct. there is a process started for each workspace root, as expected.

I'm not very familiar with the code base, but https://github.com/DetachHead/basedpyright/blob/main/packages/pyright-internal/src/analyzer/pythonPathUtils.ts#L105 (findPythonSearPaths) seems like it might be an interesting place to start. VSCode will identify the test file as belonging to workspace root b but I wonder if workspace root somehow gets set to the parent here?

Here's a snippet from the logs. In particular, notice that the root project's interpreter seems to be resolved instead of the b workspace interpreter.

file:///Users/shawn/Code/multi-workspace/b/src
Searching for source files
[Info  - 12:47:59 PM] Found 2 source files
Attempting to resolve using local imports: __builtins__
Attempting to resolve using root path 'file:///Users/shawn/Code/multi-workspace/b/tests'
Attempting to resolve using root path 'file:///Users/shawn/Code/multi-workspace/b'
Attempting to resolve using local imports: b.greet
Attempting to resolve using root path 'file:///Users/shawn/Code/multi-workspace/b/tests'
Attempting to resolve using root path 'file:///Users/shawn/Code/multi-workspace/b'
[BG(1)] analyzing: file:///Users/shawn/Code/multi-workspace/b/tests/test_greet.py ...
[BG(1)]   parsing: file:///Users/shawn/Code/multi-workspace/b/tests/test_greet.py (5ms)
[Info  - 12:47:59 PM] Could not import 'b.greet' in file '/Users/shawn/Code/multi-workspace/b/tests/test_greet.py'
[Info  - 12:47:59 PM]   Looking in stubPath 'file:///Users/shawn/Code/multi-workspace/typings'
[Info  - 12:47:59 PM]   Attempting to resolve stub package using root path 'file:///Users/shawn/Code/multi-workspace/typings'
[Info  - 12:47:59 PM]   Attempting to resolve using root path 'file:///Users/shawn/Code/multi-workspace/typings'
[Info  - 12:47:59 PM]   Looking in root directory of execution environment 'file:///Users/shawn/Code/multi-workspace'
[Info  - 12:47:59 PM]   Attempting to resolve stub package using root path 'file:///Users/shawn/Code/multi-workspace'
[Info  - 12:47:59 PM]   Attempting to resolve using root path 'file:///Users/shawn/Code/multi-workspace'
[Info  - 12:47:59 PM]   Looking for typeshed stdlib path
[Info  - 12:47:59 PM]   Looking for typeshed stdlib path
[Info  - 12:47:59 PM]   Attempting to resolve using root path 'file:///Users/shawn/.cursor/extensions/detachhead.basedpyright-1.23.2/dist/typeshed-fallback/stdlib'
[Info  - 12:47:59 PM]   Typeshed path not found
[Info  - 12:47:59 PM]   Finding python search paths
[Info  - 12:47:59 PM]   Executing interpreter: '/Users/shawn/Code/multi-workspace/.venv/bin/python'
[Info  - 12:47:59 PM]   Received 0 paths from interpreter
[Info  - 12:47:59 PM]   No python interpreter search path
[Info  - 12:47:59 PM]   Looking for typeshed third-party path
[Info  - 12:47:59 PM]   Looking for typeshed stubs path
[Info  - 12:47:59 PM]   Typeshed path not found

[DetachHead]

thanks for making a repo, it helps a lot when reproducing issues like these. though unfortunately i can't seem to get that workspace working at all. it just keeps spamming me with these errors:

it seems to want me to set a python interpreter for the workspace root as well as the two projects inside it, but attempting to select one doesn't actually do anything. im pretty sure this is the fault of the python extension rather than (based)pyright though

in my experience workspaces are an extremely broken feature and i don't know any extensions that work well with them. i just use separate vscode windows for each project to avoid these problems entirely.

im guessing the issue you're encountering is is that pyright doesn't have a way to use two interpreters at the same time. this might be the same issue as #384, in which case i might re-open it and investigate further

[strangemonad]

let me see if there's anything wrong with the repo and why it was working locally for me.

Although they certainly could have some improvements, I don't know that my experience with mutli-root workspaces have been quite as bad as you describe. The ability to go to all files and symbols across related projects via cmd-p, cmd-t is pretty hard to ignore vs vscode window switching.

[strangemonad]

im guessing the issue you're encountering is is that pyright doesn't have a way to use two interpreters at the same time. this might be the same issue as #384, in which case i might re-open it and investigate further.

I don't think that's the core issue from my very light initial investigation. I believe there's a single pyright / lsp process per workspace root and those are initialized with the correct venv. However, that's not the venv that seems to be used when resolving the imports.

[DetachHead]

I believe there's a single pyright / lsp process per workspace root and those are initialized with the correct venv

nah it doesn't. there are two ways the basedpyright extenstion can start the lsp process, and neither of them are currently capable of starting multiple processes per workspace folder:

• when basedpyright.importStrategy is "fromEnvironment" (the default), it uses the python extension api to determine the currently selected environment which, as far as i can tell, only allows one to be set at a time.
• when basedpyright.importStrategy is "useBundled" (the same behavior as pyright), it uses the version of the language serrver bundled with the extension. it always starts up one instance of it regardless of how many folders are in the workspace

it might be possible to use a single process and have it work with both workspace folders, but i dont like this idea because it defeats the purpose of pinning the project's basedpyright version

maybe we need to implement our own python environment picker thing for workspaces?