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
Cannot resolve google.cloud imports when types-protobuf are installed #2113
Comments
I'm receiving a similar error message from mypy:
The problem is that the |
Okay, thanks for the info |
The one thing that confuses me is that currently typeshed has no py.typed files |
The typeshed stubs are not "stub-only packages" as defined by PEP 561 — i.e. they're not installed directly in the |
I wanted to fix python/typeshed#5800 and came across a problem I think is more suited to be commented here rather than on the typeshed issue. I actually tried out the attempt with the The
Using the given reproducer:
and run it against
No trouble. I install another
And rerun
it doesn't pick up the types because the protobuf stubs are installed. Now you might say, hang on a tick here. The
The Shouldn't I removed my virtualenv a few times because I ended up confused with the reproducer and the results. I think, uninstalling the 'typeshed-protobuf' package leaves the |
I'm a bit confused about all of the locations where you have type stub files associated with the
That is the search order that pyright uses when attempting to resolve an import, consistent with PEP 561. Looking at the pyright logs above, it doesn't appear to find any It doesn't find a
It's finding an
So I see a couple of issues here. First, I'm not sure why pyright is not finding a |
Yes I'm pretty sure. I went back today, removed the virtualenv and recreated it. Then installed
The uploader would generate a similar package for any other google namespace package in typeshed at the moment. I think that has to be addressed in typeshed (see python/typeshed#5800)
I think there must be a problem with the traversal? Because the
I actually did remove the
|
I published pyright 1.1.161, which improves the logging for import failures. Could you please install the updated version of pyright and paste the logged output? Thanks! |
Ok, here we go. I removed the old virtualenv, and recreated a new python3 venv. Installed
I thought it might be useful to have a diff too: -/tmp % foo/node_modules/.bin/pyright test.py --verbose 1 ↵
+$ foo/node_modules/.bin/pyright --verbose test.py
No configuration file found.
No pyproject.toml file found.
stubPath /tmp/typings is not a valid directory.
@@ -18,19 +18,20 @@
Attempting to resolve using root path '/tmp/foo/node_modules/pyright/dist/typeshed-fallback/stdlib'
Typeshed path not found
Looking in stubPath '/tmp/typings'
- Attempting to resolve using root path '/tmp/typings'
+ Attempting to resolve stub package using root path '/tmp/typings'
Attempting to resolve using root path '/tmp/typings'
Looking in root directory of execution environment '/tmp'
- Attempting to resolve using root path '/tmp'
+ Attempting to resolve stub package using root path '/tmp'
Attempting to resolve using root path '/tmp'
Looking in python search path '/usr/lib64/python3.9'
- Attempting to resolve using root path '/usr/lib64/python3.9'
+ Attempting to resolve stub package using root path '/usr/lib64/python3.9'
Attempting to resolve using root path '/usr/lib64/python3.9'
Looking in python search path '/usr/lib64/python3.9/lib-dynload'
- Attempting to resolve using root path '/usr/lib64/python3.9/lib-dynload'
+ Attempting to resolve stub package using root path '/usr/lib64/python3.9/lib-dynload'
Attempting to resolve using root path '/usr/lib64/python3.9/lib-dynload'
Looking in python search path '/tmp/python3/lib/python3.9/site-packages'
- Attempting to resolve using root path '/tmp/python3/lib/python3.9/site-packages'
+ Attempting to resolve stub package using root path '/tmp/python3/lib/python3.9/site-packages'
+ Resolved import with file '/tmp/python3/lib/python3.9/site-packages/google-stubs/__init__.pyi'
Looking for typeshed path
Looking for typeshed stubs path
Attempting to resolve using root path '/tmp/foo/node_modules/pyright/dist/typeshed-fallback/stubs/protobuf'
@@ -38,6 +39,6 @@
Typeshed path not found
/tmp/test.py
/tmp/test.py:1:6 - error: Import "google.cloud" could not be resolved (reportMissingImports)
- /tmp/test.py:6:13 - info: Type of "__version__" is "bytes"
+ /tmp/test.py:4:13 - info: Type of "__version__" is "bytes"
1 error, 0 warnings, 1 info
-Completed in 0.56sec
+Completed in 0.574sec |
@romanofski, is this still a problem? I'm having trouble understanding which stub files are present in your site-packages. The two versions of the logs that you posted seem to indicate that you had different stub files present in each case. That explains part of the differences you see above. Based on the most recent logs, it looks like there was no At this point, I recommend trying to repro this from scratch with a clean venv. If you are still able to repro a behavior you consider to be a bug, then I'd appreciate step-by-step instructions for how to recreate the problem. Thanks! |
Thank you, will do. My apologies for the inconvenience this has caused. |
No worries. I'm going to mark this issue as closed for now. I'm happy to re-open it if you find that problems remain. |
Hiya! I was able to minimally repro this with Here's the output
I suspect that the source of issue here is that The I considered "fixing" the
(I can't reopen the question, because I wasn't the original author @romanofski) |
I did find that PEP561 says
I am trying to understand the meaning of |
"module-only" means it's distributed as just e.g. |
Thanks @nipunn1313 for the clear repro steps. After investigating this further, I think pyright is doing the right thing here. The problem is that the PEP 561 is unequivocal in saying:
If I manually add a If my read is correct, then mypy has a bug in its import resolution logic. In the absence of the Let me know if you agree with that analysis. |
Heya @erictraut - thanks for taking a look. PEP561 also says
which contradicts
I am trying to make some modifications to PEP 561 to clarify. I don't think it makes sense for I believe the behavior I'd expect is for distributions like I realize this is breaching the realm of PEP design decisions rather than a pure bug, but I think it's what it'll take to make progress here. |
Thanks for the additional explanation. If I understand you correctly, you don't expect the sample above to work unless I've changed pyright's import resolution logic to handle this case accordingly. If I run your batch file and then manually delete |
Yep - that explanation matches my understanding. I think it should be considered a bug in |
Thanks, I appreciate your leadership on this issue. This change will be in the next release of pyright, probably published around midweek next week. |
This is addressed in pyright 1.1.174, which I just published. It will also be included in the next release of pylance. |
Cool Thanks! Note that the original issue won't be solved until python/typeshed#6106 gets through - but I think pyright's side of the equation has been adjusted appropriately! |
@nipunn1313, given that python/typeshed#6106 was reverted, what's the best current solution for Pyright with this issue? It seems that |
Are you using the typeshed stubs bundled with pyright, or are you using your own? When I sync the typeshed stubs that are bundled with pyright, I manually delete the In the meantime, you could manually delete the |
I've installed I've removed When running pyright, it still cannot resolve the |
@joshtemple you have to remove |
Thank you! That solved it for me. |
Since the fix was reverted and the issue still remains, can this be reopened? It would have saved me some time I spent searching if the issue was still open. |
@aabmass, I'm not sure what you mean by "fix was reverted". Pyright is working as designed, so there's no bug to fix here. If you are seeing a different issue that you believe is a bug, please open a new issue with the details. |
Describe the bug
When
types-protobuf
stub is installed,google.cloud
imports cannot be resolved. I don't think it's a stub bug, because mypy seems to handle this right.To Reproduce
In a fresh venv:
Expected behavior
No errors
Screenshots or Code
from google.cloud import firestore
VS Code extension or command-line
Running pyright 1.1.157 with npx
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: