Run mypy in CI #3492
Run mypy in CI #3492
Conversation
| JUPYTER_PLATFORM_DIRS = 1 | ||
| PYTHONWARNDEFAULTENCODING = 1 | ||
| commands = python -m pytest -n auto -v {posargs:tests} | ||
| commands = python -X PYTHONWARNDEFAULTENCODING -m pytest -n auto -v {posargs:tests} |
There was a problem hiding this comment.
I changed this because mypy raises encoding warnings when the env var is set. See also #3154
There was a problem hiding this comment.
Why does mypy raise encoding warnings when the env var is set? 🤔
jokasimr
left a comment
There was a problem hiding this comment.
Looks good to me! Left a few questions.
There was a problem hiding this comment.
There were several files in different directories that have the same name. Mypy does not like this because it treats every file as a Python module and those need to be unique.
| JUPYTER_PLATFORM_DIRS = 1 | ||
| PYTHONWARNDEFAULTENCODING = 1 | ||
| commands = python -m pytest -n auto -v {posargs:tests} | ||
| commands = python -X PYTHONWARNDEFAULTENCODING -m pytest -n auto -v {posargs:tests} |
There was a problem hiding this comment.
Why does mypy raise encoding warnings when the env var is set? 🤔
I don't know. All I could find is this: python/mypy#17057 and this: realpython/pytest-mypy#152 But they relate to pypy and pytest-mypy which we don't use. |
There were pairs of files with the same name. This made mypy unhappy.
This run mypy in PR builds and on main. It excludes a large number of files which have not been fixed to pass type checks yet. But these tests should prevent backsliding in files that have already been updated.
The mypy run is part of the same job as other tests because it requires the C++ package to be built. We may ultimately want to split it off. This could, e.g., be achieved by uploading the binary as an artefact.