Global module import for multi root workspace

[Griperis]

Hello,
I have read through several issues and didn't find an answer or resolved what is or should be correct behaviour for this case.

We have a multi-root workspace with several folders defined in .code-workspace (fld1, fld2) settings and one third party folder which contains modules.

root/xyz/fld1/file.py
root/uvw/fld2/file.py
root/3rd/module

Having settings with python.analysis.extraPaths: ["3rd/module"] resolves into a separate 'search path' for each workspace folder instead of for the root workspace as I would have expected.

Environment data

• Language Server version: 2021.6.1
• OS and version: Windows 10.0.19043
• Python version (& distribution if applicable, e.g. Anaconda): 3.9

Expected behaviour

Search paths passed to pylance:

fld1/
/3rd/module

The path from extraPaths is absolute to the workspace and is not dependent on the workspace folder path, where the currently edited python file lies.

Actual behaviour

Search paths passed to pylance:

fld1/
fld1/3rd/module

The /3rd/module path is appended to the fld1 or fld2 path depending on the place where the python file is edited.
I would expect using python.analysis.extraPaths: ["./3rd/module"] is going to result in this behaviour instead, but it works the same.

[jakebailey]

I think that this is working as expected. The paths 3rd/module and ./3rd/module are the same path. Path-related settings are rooted relative to the workspace. Paths inherited from a code-workspace or user settings.json file are not distinguishable from per-workspace settings.

When you're using multi-root workspaces, you have multiple workspaces, each with their own roots. You would need to configure each of their settings individually. Can you try specifying the paths per-root instead? i.e. in each's settings, versus in code-workspace?

[Griperis]

I think then that's my misunderstanding of how VSCode workspaces work. I expected that there is a root workspace containing some other workspaces defined in the .code-workspace "folders", isn't that the case? Isn't there an ability to have 'root workspace' settings applied for every workspace the same way and then relative settings in the sub-workspaces?

Using settings individually is for sure possible, but I don't think that it scales well with our approach. Adding one library results in adding multiple paths at multiple files.

[jakebailey]

VS Code configuration is layered; when you query it, you get the setting for the specific workspace, then if not present, the setting from code-workspace, then if not present, the user configuration. From the querier's point of view, you're just getting a value back. Language servers get that final merged information and have no idea that the setting was set it one place versus another and that maybe the intent was for it to be relative to some other locations.

There are things we can do to try and ask VS Code for the raw settings at each layer, but this is sort of leaving the realm of the way that VS Code settings and the LSP were designed.

[Griperis]

Seems that my expectations are against the design of VSCode. Thanks for the explanation.