--install-types can mask failure details

[tk-woven]

Bug Report

When no .mypy_cache folder exists and a user runs mypy --install-types --non-interactive ./, mypy may fail on fundamental issues but suggest that the failure was because of "no mypy cache directory," confusing the user.

To Reproduce

I've created a minimum reproducible example. Please find it here.

I summarize the example below.

Expected Behavior

For the source tree

.
├── a
│   └── lib.py
├── b
│   └── lib.py
└── main.py

where all files are empty except main.py, which might contain

def f(i: int = 0):
    i = "test"  # This is a mypy violation.
    print(i)

if __name__ == "__main__":
    f()

we expect running mypy --install-types --non-interactive ./ at the root of the source tree to either (1) generate the .mypy_cache and then report any typing errors or (2) explain why it cannot generate the cache.

Actual Behavior

mypy fails because b.lib duplicates a.lib by name in the same module. However, mypy does not report the duplicate module error. Instead, it only reports error: --install-types failed (no mypy cache directory).

This behavior is particularly confusing in CI, where our environment has no preexisting .mypy_cache and where an unsuspecting user may accidentally cause the duplicate-module behavior. mypy fails and suggests it's because of the missing cache directory.

(Deeper demonstration is in the reproducible example linked above. In short, if mypy finds an empty .mypy_cache folder, it will report the duplicate module issue. If we place __init__.py in a and b and remove .mypy_cache, mypy will install the cache correctly and report the typing error.)

My Environment

• Ubuntu 20
• Python 3.6 (this older version is from the production codebase in which we found this issue)
• mypy 0.910

Related to #10600 .