Open memeplex opened 4 years ago
memeplex
commented
4 years ago I've submitted this to the python extension tracker also, as you can see above, so in case you need more information about the environment where the problem is happening you can check that there.
jakebailey
commented
4 years ago The language server doesn't support multi-root workspaces directly. It relies on the extension to spawn multiple language servers per workspace, which requests are directed to. This can lead to some bad effects if those workspaces are all entirely different projects, which is what I think you're seeing here.
You're combining multiple folders which are not in one common place. They're being given as import roots, and because they're not inside the workspace root, we're considering the to be library code (not user code). That's why they're being put under the file watcher.
Additionally, we pre-scan all of the files in the workspace to build the symbols database, but we aren't scanning anything outside the workspace automatically, which would include those spurious folders. Symbols should still work, as the editor sends a didOpen notification to give us the file that's open (and the symbols should be processed there), so that doesn't make sense. If you edited a file, then we get a change request, which would edit our in-memory copy, and symbols would change, but all of that is stored in the same place and should be working no matter if you've edited or not.
memeplex
commented
4 years ago You're combining multiple folders which are not in one common place.
I'm not sure how to interpret this statement but they are all immediately below the same root folder.
they're not inside the workspace root,
Again, I'm not sure about the precise meaning of that, what I can tell is that the workspace settings file is located in another folder than these project folders, but also that there is no concept of workspace root in vscode AFAIK. Again, the project folders are all together below the same directory in the file system.
jakebailey
commented
4 years ago The workspace root is the folder you open in VS Code via "Open Folder" (or starting VS Code in a folder by running something like code . in the terminal). It matters which folder that is when dealing with imports, though in your case may be affecting symbols.
If you're not opening any one specific folder, then I'm not entirely sure what workspace folder we'll use (and we should probably have a log message for the root being used).
memeplex
commented
4 years ago I'm working in a multi-root workspace. AFAICS the thing that represents that workspace in the file system is a settings file and not some kind of root folder. This is different from a folder in that workspace which is related to, well, a folder in the file system. Do you have any idea where can I look for that log you mentioned?
jakebailey
commented
4 years ago To be clear, I meant that we don't print the workspace root on startup and that we should (#1538), not that we do already.
DonJayamanne
commented
4 years ago @jakebailey
Do you have an idea of what the problem is? Ie. Can you replicate this at your end with a simple setup? Is this an issue with the extension or ls? Or is it a dup of https://github.com/microsoft/vscode-python/issues/5132
jakebailey
commented
4 years ago It's very likely related, though I would think that any spawned language server should be able to produce the outline for any file regardless of its location, so should work anyway. I have not yet had the time to construct an example which shows this yet, no.
jakebailey
commented
4 years ago 
sepich
commented
4 years ago I would add, that you can have just one workspace but then open file from outside and it would have no outline. Works fine in Jedi though.
jakebailey
commented
4 years ago Ah, I can see how this might be breaking; documents outside of the workspace are considered library code, so we throw away their file contents to save memory. It's possible the indexer is getting the document from the table, then indexing nothing because we've thrown away the info the indexer needs.
memeplex
commented
4 years ago Has there been any advance in this front? Features are being added to vscode-python that depend on this language server that still violates a basic contract of vscode (multi-root workspaces).
jakebailey
commented
4 years ago As far as I know, there has been no change. Generally, LSP and multi-root workspaces don't play well together when multiple LSs are being used due to the requests needing to be sent to the right place. See microsoft/vscode-python#5132, where I described the issue; the extension needs to provide the LS lib with a "document selector" that is used to tell VSC where to send requests. In a single workspace, all requests get funneled to the language server for that language, but with multi-root multi-LS workspaces, you now have to pick what goes where (and can't handle files that aren't within those workspaces, i.e. the issue in this thread). A solution could be to use a single LS for everything and have it figure out what to do, but that's moving the problem elsewhere and will take careful consideration.
Environment data
Expected behaviour
Every python file in any of my projects in the workspace gets a proper outline.
Actual behaviour
When I launch vscode and there is an open file, files for that project generally get an outline. But files for other projects often don't. This is not "fixed" by editing the source file like other reports might suggest. The only fix I've found is to restart vscode with that file open, but then other files in other projects fail to get their outline... One thing is sure: when a file for a project gets an outline, all files for that project also get one, and, conversely, when a file for a project doesn't get its ouline, all the project is doomed.
The problem is not observed when using Jedi instead of MS-PLS.
One thing that surprises me is that I get:
while my workspace config is:
So Macross is not required while Gcd is missing in the PLS log.
All of the projects are installed with pip using
--user -e .and accessible from any python REPL.Logs