Skip to content
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

Cache causes mypy to fail every 2nd run for module importing from google.cloud #13085

Closed
MaxG87 opened this issue Jul 7, 2022 · 3 comments · Fixed by #13124
Closed

Cache causes mypy to fail every 2nd run for module importing from google.cloud #13085

MaxG87 opened this issue Jul 7, 2022 · 3 comments · Fixed by #13124
Assignees
Labels
bug mypy got something wrong topic-incremental

Comments

@MaxG87
Copy link

MaxG87 commented Jul 7, 2022

This is very similar to #12232. However, I had to modify the minimum working example, because mypy==0.961 fixed the other one.

Bug Report
I have a project that imports things from google.cloud, which is a namespace package as far as I know. In a certain, very specific configuration mypy fails on every second run. This is very similar to #9852 and an almost duplicate of #12232. However, this bug affects the most recent mypy, 0.961. Since the reproducer of #9852 and #12232 are fixed, I open a new bug report.

To Reproduce

The following script does reproduce the problem on Debian Stable and inside the Docker image python:latest.

#!/usr/bin/env bash

VENV=$(mktemp -d)

rm -rf "$VENV"

# The order of the imports matters. If one imports datastore first, the error
# does not occur. Also, one must suppress the type error on the import of
# `storage`, otherwise the error does not appear neither.
cat <<EOF >script.py
from google.cloud import storage  # type: ignore[attr-defined]
from google.cloud.exceptions import NotFound
EOF

python3 -m venv "$VENV"
source "$VENV/bin/activate"
python3 -m pip install mypy==0.961 google-cloud-storage==2.0.0 google-cloud-datastore==2.4.0

mypy script.py
mypy script.py
mypy script.py
mypy script.py

Expected Behavior
Pass or fail every time. I am not sure what would be correct in this case.

Actual Behavior
Mypy accepts and rejects the code every 2nd run.

Your Environment

Debian Stable and python:latest. The reproducing script should cover all relevant details.

@MaxG87 MaxG87 added the bug mypy got something wrong label Jul 7, 2022
@hauntsaninja
Copy link
Collaborator

Thanks for reporting this, can reproduce. I'm sorry that mypy's been doing a such a shoddy job here. There's an element of mypy's module finding logic with respect to namespace packages that is stateful and is the root cause of all this repeated pain. In Guido's words, four years ago: #5016 (review). I'll see if there's yet another small patch that will fix, but I think this might be hard to make bulletproof and be confident about until we rip out that stateful logic. At least test suite will prevent regressions :-)

@hauntsaninja
Copy link
Collaborator

Okay, I have a patch that fixes this. I think I wrote the same patch last time, but can't remember why I didn't commit it. I think it changed module processing order or something.

@MaxG87
Copy link
Author

MaxG87 commented Jul 7, 2022

I'm sorry that mypy's been doing a such a shoddy job here.

This particular case might work bad, but rest assured that mypy is one of the most important tools in my Python toolchain. Thank you all very much for providing such a great tool that does an incredible job almost all of the time.

@hauntsaninja hauntsaninja self-assigned this Jul 8, 2022
JukkaL pushed a commit that referenced this issue Jul 20, 2022
Fixes #13085. Hopefully more robust than previous fixes along these lines.

Co-authored-by: hauntsaninja <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong topic-incremental
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants