Repository navigation
Fix "go to definition" and resolving imports #466
Description
Activity
- added a commit that references this issue
on Dec 7, 2018 Matthias Osswald (@busykoala) A new build with #467 is in progress and should show up in daily in a bit.
Thank you very much!
The version I tried now, could resolve imports again with given settings.
Not yet solved in my case is 'go to definition' which once was working properly (about three days ago).
The output I get when trying to jump to a definition is following:[Error - 12:09:05 AM] Request textDocument/definition failed. Message: PriorityProducerConsumer`1 instance is disposed Object name: 'PriorityProducerConsumer`1'. Code: -32000 at Microsoft.PythonTools.Analysis.Infrastructure.DisposeToken.ThrowIfDisposed() at Microsoft.PythonTools.Analysis.Infrastructure.PriorityProducerConsumer`1.Produce(T value, Int32 priority) at Microsoft.PythonTools.Intellisense.AnalysisQueue.ExecuteInQueueAsync(Func`2 function, AnalysisPriority priority) at Microsoft.Python.LanguageServer.Implementation.Server.WaitForCompleteAnalysisWorker(CancellationToken cancellationToken) at Microsoft.Python.LanguageServer.Implementation.Server.FindReferences(ReferencesParams params, CancellationToken cancellationToken) at Microsoft.Python.LanguageServer.Implementation.Server.GotoDefinition(TextDocumentPositionParams params, CancellationToken cancellationToken) at Microsoft.Python.LanguageServer.Implementation.LanguageServer.GotoDefinition(JToken token, CancellationToken cancellationToken)Rather than this file structure
some/other/package_xonly is a symlink. This is pretty handy to have shared packages and is common use in plone projects.root │ main.py │ ├───project │ __init__.py │ └───some └───other └───package_x -> Users/username/.buildout/eggs/package_xAs I mentioned to avoid infinit loading on 'go to definition' it yet (and still) is necessary to search exclude
**/some/other.
The folder is added again with"python.autoComplete.extraPaths":["${workspaceFolder}/some/other", ],Is there an error message before that disposed message? That should only occur after an exception occurs in a different part of the code (#448), but the initial error should be in the same output panel.
Well I think it's not really an error message except of 'no definition found for...' in the vscode gui.
Getting hover for package_name Waiting for parsing to complete. Parsing complete. Waiting for analysis entries to enqueue. Enqueue complete. Waiting for analysis to complete. [Error - 12:39:21 AM] Request textDocument/definition failed.But it doesn't seem to scan the additional files initially. So the output makes sense.
Matthias Osswald (@busykoala) , I've tried to recreate the file structure with symlink, but for me
go to definitionworks as expected. If you have minimal repro, can you pack it into zip or tarball and attach to the bug?I've just tried different repositories with the same structure.
In smaller project it worked having these two lines in my settings:
"python.autoComplete.extraPaths": ["${workspaceFolder}/parts/omelette", ], "python.autoComplete.typeshedPaths": ["${workspaceFolder}/parts/omelette", ],With bigger projects it's not working. Therefore I guess it is regarding the size of projects. I'm sorry I didn't figure that out before.
Thank you for the help and let me try python language server when it advanced a little more.
24 remaining items
Matthias Osswald (@busykoala) - the exception should be fixed in 0.2.36 that is coming out ~ March 29th
Once in a file from the omelette I couldn't go to definition at all (for my tested cases).- #840.Since the item is evolved with many cases fixed, I am closing it. Please open new issues for the cases you still discover. Thanks.
Has this stopped working again? It works with
python.jediEnabled: true
What is the message being squiggled? If the import isn't resolved, then it won't be able to find the definition.
I believe it's a linter complaining about lack of module documentation. The import should be valid.
A linter meaning an external linter, or a message generated by the language server? (It'll say
(Python)in the hover if it's from the LS, otherwise the name of the linter.)Also, what's in your
.env? Are you setting PYTHONPATH? Similarly, are you setting extraPaths in your VS Code settings?It's an external, pydocstyle.
.env:PYTHONPATH="."I'm not setting extraPaths in vs code settings.
When I hover it says it sees it as a module.You're at the latest version, correct? I recently fixed some things related to setting a path to
.(which should be redundant, as the opened folder itself is a search path). Are variables from that imported module accessible, or are they not listed?Since I think it's getting resolved, it's probably not related to the
PYTHONPATH=.fixes. I'd appreciate it if you could open a new issue with that project attached (zipped, if you're willing to upload it).I'm running 2019.3.6558 (8 April 2019) of vs code python extension. Not sure if there are any steps I need to do to upgrade LS? I'll create a new issue.
The LS version is different from the extension; you can find the language server version printed in the Python output panel (or in the directory name for the download inside the Python extension's folder).
- added a commit that references this issue
on Nov 1, 2019
I have
"python.analysis.downloadChannel": "daily"activated.The update two days ago broke the 'go to definition' feature for my setup.
I'm using vscode and it's regarding a large plone project using the omelette as described below.
To avoid language server load infinitely (which would be another issue, maybe related to this), I excluded the
parts/omelettewithsearch.exclude.Below that in the settings, I added the
parts/omelettewith:"python.autoComplete.extraPaths": ["${workspaceFolder}/parts/omelette", ],which seemed to work for the last few days now.By 'it seemed to work' I mean it could resolve the omelette imports and jump to definitions.
Now it sais 'no definition found for...' and the imports can't be resolved anymore.
For what I can see in the output, before the update, it used to analyse from
autoComplete.extraPath, which it does not anymore since it updated the language server today.(
parts/omelettecontains symlinks to cross-project sources in a local directory.)