This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
typing_extensions isn't found in <repo>/<worktree>/src/
#6150
Comments
|
@erictraut is the best person to answer this, but I believe it is by design given our import resolution order described here: https://microsoft.github.io/pyright/#/import-resolution?id=resolution-order. Here are some ways you could fix this:
|
Note that it doesn't complain if I rename
Somehow this step is being skipped for
That won't work, as the libraries can be optionally installed.
I don't think that will make a difference, I'm getting this error if
It's very convenient to have the different branches of the repository as subfolders (work trees) of the workspace root. Shouldn't it only report shadowed imports if it can't find the imported symbol, but it's present in the shadowed module? |
|
I don't want to write |
Yes, that's because when you import
It's not skipped really. We never get there. We found
Hmmm, it worked for me and I don't have
The shadowed import diagnostic is not about a symbol, but rather a module -- in these scenarios it's warning that your local
What happens when it's not installed? If you don't have |
If it can't resolve the module, it should move on the step 6:
It will be better to explain with an example: https://github.com/nineteendo/pyvz2/tree/alpha If you download this repository you can run the Here's the thing: if I don't include So, this means that I freeze |
Yes, but it did resolve the module. It found it in Pylance's bundled copy of typeshed.
It needs to be under I'll try your repo later today. |
|
The I'm not that familiar with the code in pyright that tracks "shadowed" modules (i.e. ".py" files that correspond to ".pyi" files). This functionality was added by the pylance team (along with the |
|
Yeah, I think that's exactly what's happening. That also explains why it gives this error if I open the worktree directly: "/Users/wannes/Library/CloudStorage/OneDrive-Personal/Personal/GitHub/pyvz2/alpha/src/typing_extensions.py" is overriding the STDLIB module "typing_extensions" So, that error message is not even correct. |
|
Changing the shadowed import diagnostic behavior isn't going to change how the import is resolved though. Are you saying that one of the alternatives I listed above would work for you, except for the diagnostic? If that's the case, while we consider whether to change the diagnostic's behavior with |
StellaHuang95
added
the
waiting for user response
|
It's fine to resolve to the stub file, but isn't there a second kind of resolving going on:
Right now I'm suppressing the error with |
github-actions
bot
added
user responded
Yes, we do a separate resolution to look for the source file, and in this case we don't do step 6 in the resolution order that we were discussing above. I agree that this is a bug, but it's not clear to me that it impacts a large number of users. Wanting to match a library/built-in stub with a user source file seems unusual. Without feedback from more users indicating that this is problematic, it's unlikely that we will prioritize fixing it. Therefore, I'm inclined to treat this as an enhancement and move it to discussions to see if other users up-vote it.
Note that you can suppress the |
debonte
added
bug
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Environment data
Code Snippet
repo/main/src/typing_extensions.py: typing_extensionse239100Directory tree
Expected behavior
No warnings, I'm bundling a version of the third-party
typing_extensionsmodule, not a module from the stdlib.Actual behavior
Logs
The text was updated successfully, but these errors were encountered: