Set mypy to only run on pre-push

[clbarnes]

Type checking is very slow (while we await our rust-based saviours ty, pyrefly, pylyzer...) which discourages modular one-job commits and small fixes. It would be great to have every commit fully type checked but the DX is not great.

[tlambert03]

hmm, for me, locally, on main, it's slow (13 sec) with a cold cache on the first run (after clearing mypy_cache), but subsequent runs take 1.5 seconds... which I'm fine with. Most of that first run is also caused by indexing bokeh and other third party extensions (which we could further ignore and optimize in the config).

On #106, that first run has gone up to 77 seconds, and subsequent runs take a similar amount of time ... so this looks like it might be something specifically caused by #106, which I'd rather tackle with a smarter config.

[tlambert03]

yeah... it's specifically caused by the new _colormapname.pyi file.

I tried

[tool.mypy]
exclude = "^_colormapname\\.pyi$"

but that didn't help, presumably because _colormap.py still imports it when defining ColormapLike. This does actually raise some concerns about #106 in general... I wonder whether shipping that file in the distribution might be problematic (since the IDE of anyone using cmap will now have to parse a 2600 line Literal?)

[tlambert03]

I just made a new project, installed cmap 73bfe5e and mypy, and just ran mypy on a single file:

from cmap import Colormap

cm = Colormap("accent")

with ColormapName in the ColormapLike Union, it took 25 seconds on the first run, and anytime I modify the file such that it considered the cache stale (i.e. anytime you change the colormap argument or do anything to see this in the mypy logs):

LOG:  Processing SCC of size 6 (cmap._external cmap._util cmap._catalog cmap._color cmap._colormap cmap) as stale due to deps (cmap._png numpy numpy._core.function_base numpy._core.multiarray numpy._core.shape_base numpy._typing numpy._typing._array_like numpy._typing._dtype_like numpy.typing)

(immediately rerunning without modifying the file takes only 0.024 seconds). So, that does suggest that there is a very real cost to end-users by merging #106. @clbarnes ... what are your thoughts?

[clbarnes]

Ah, that is a shame. I think it's a no-go, then - a change intended to boost the DX shouldn't then cripple it!

I may have a tool around to see if there's any other way of achieving the discovery/ autocomplete (e.g. generating a static class with members which are str or a namespace), but that may hit the same problem, I suspect it depends on what mypy is doing under the hood.

[tlambert03]

yeah, I'm afraid this and #106 may have to be shelved. It's a very nice feature, but will cause performance issues for those using mypy or pyright. I'm afraid the documentation search may have to suffice until we figure out a better way. Please reopen if you come up with anything!