jump to definition doesn't work sometimes for symbols imported from top level of module #733
Comments
|
The main from . import constantsfrom .constants import *__all__ = ["constants"]If you use any of these techniques, |
jakebailey
added
the
waiting for user response
|
Thanks! Here are the versions I tried, I would restart vscode each time and observe the highlighting in # from . import constants
# __all__ = [
# "constants",
# ]
# from . import constants
# __all__ = [
# constants,
# ]
# from pylance_test_package import constants
# __all__ = [
# "constants",
# ]
# from pylance_test_package import constants
# __all__ = [
# constants,
# ]
# from pylance_test_package import *
# __all__ = [
# "constants",
# ]
# from pylance_test_package import *
# __all__ = [
# constants,
# ]
# from . import *
# __all__ = [
# "constants",
# ]
from . import *Unfortunately I still get the same issue in all cases. I did notice something though:
One suspicious thing here is that the folder and the python module have the same name. There's no |
|
Is your import root a subdirectory of your workspace? That's what it seems like; we assume the workspace root is where imports are rooted from unless you specify extra paths to be import roots: https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#unresolved-import-warnings |
|
I don't think I have an import root in the sense you mean. We have a tree of directories, some of which contain python packages, and those are installed like this package, |
|
Editable installs are a case we don't fully support yet, so there may be some troubles there: #78 |
|
Oh good to know. So is the preferred method that I crawl the directory tree and build up some sort of composite import root of all directories with a |
|
Most people only ever have to set one or two import roots; I wouldn't expect you to write tooling to make it work. Editable installs should be handled such that installing a package marks it as an import root, which is what #78 is about (we handled this in MPLS and should here, but we've been working on other things). |
|
Of course, if you do make the giant list and try it out, and it works, that'd be helpful to know as the behavior should be somewhat similar if editable installs are fixed (as that's effectively the same thing). |
|
Great, thanks for the help! Should I close this issue in favor of #78? Since my packages are arranged in a tree and not a list, I think I'd need one of:
|
|
Actually @jakebailey I'm seeing this even if I install the package normally (pip install, no -e flag). Is it just my machine? |
|
I think I'd be interested in seeing the trace logs in that situation, specifically the bit where we print the search paths being used. If they're properly installed and in a search path, they should work, but it's a bit hard to guess based on your description the actual layout on disk. |
|
So for this issue (not the directory tree thing, which is where I first saw this), I included a zip file of the code to reproduce the issue. I tried again with the installed package and with trace logging enabled: |
|
@jakebailey do the trace logs reveal anything interesting here? |
|
Assuming you haven't set any extraPaths (which we aren't printing; need to work on that), not exactly. Are these packages installed into site-packages, or are they editable and are being installed via some pth file? Or, are they being installed as zipfiles (something I had forgotten is a thing in python). (It's not likely that we'll have a massive amount of bandwidth to look at things for a while; holiday season and nearly everyone including me are about to take a break... Sorry about response time looking at these.) |
|
That last trace was done with Also, totally understand about bandwidth. Just wanted to figure out if it was a bug, the editable install thing, or my computer. Feel free to ignore until after the holidays. |
|
I haven't had a chance to try and run that example code yet, no. I'll switch the label so we know that it's about checking that. |
jakebailey
added
needs investigation
|
@jakebailey was this the same issue as #859 ? |
|
I'm not certain; this issue mentioned editable installs which I believe may be handled differently. My intent was to go back over all of the old import resolution / local package issues to see if the behavior changed. Are you saying that your original issue is fixed in the most recent release? I'm very curious. |
|
The issue also occurred with normal installs: #733 (comment) Seems to be fixed now, thanks! |
Environment data
Expected behaviour
I should be able to jump to the definition of imported symbols.
Actual behaviour
I sometimes cannot do this.
Logs
Code Snippet / Additional information
Zip file of example code:
pylance-import-issue.zip
Opening the folder as
code .in the root dir:Jumping to
CONSTANT1orCONSTANT2with cmd+left click works, but the symbolconstantscannot be jumped to.Opening an individual file in an empty workspace e.g.
code pylance_test_package/pylance_test_package/something.py(and after setting correct environment):Jumping to all symbols works.
The text was updated successfully, but these errors were encountered: