-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global module import for multi root workspace #1423
Comments
I think that this is working as expected. The paths 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? |
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. |
VS Code configuration is layered; when you query it, you get the setting for the specific workspace, then if not present, the setting from 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. |
Seems that my expectations are against the design of VSCode. Thanks for the explanation. |
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.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
Expected behaviour
Search paths passed to pylance:
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:
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.The text was updated successfully, but these errors were encountered: