Repository navigation
Always write the -i cache #3045
Description
Activity
It would then be cleaner to simply default to the
-ibehavior entirely and only allow a non-cache variant as an option.I'm torn about that. Historically
-imode has had a lot of instabilities around edge cases, which would make this problematic -- but some of that is because it's not on by default, so maybe enabling it by default is better because it'll get more testing. Also, at Dropbox it suffered from not flushing the cache when the mypy version changes, but that's been fixed recently (#2992).Calling for additional opinions?
Writing the cache always seems reasonable to me, since the performance overhead is pretty minor but the potential speedup from being able to use
-iis significant. Turning it off manually could be useful at least for CI jobs that won't ever run mypy twice.I feel like turning
-ion by default is a little risky, since it has historically been unstable and we don't have very good CI around it yet. Regressions to-ican still slip through quite easily. I'd suggest we wait until we have better testing around it.
I've noticed that many people initially run plain
mypyand then start usingmypy -ibut find that the first such run is not any faster than a plain run. This is understandable because it needs to warm the cache first.We could alleviate this issue by just always writing the cache (perhaps allowing this feature to be turned off for special scenarios but having it on by default). This might cost a little bit of extra run time -- IIRC I once measured the cost of writing the cache and it was in the 5-10% range.