First pass mypy typing

[bryevdv]

This PR adds begins adding Python types Cunumeric, starting with the following modules

cunumeric._sphinxext
cunumeric._ufunc
cunumeric.coverage
cunumeric.fft
cunumeric.install_info
cunumeric.linalg
cunumeric.patch
cunumeric.random
cunumeric.utils
cunumeric.window

Note the ugly mypy_path hack currently in pyproject.toml:

mypy_path = "typings/:../legate.core/typings/:..legate.core/install38/lib/python3.8/site-packages/"

This is because legate is not actually installed in the site-packages for the Python that is executing mypy. I think probably the only solution is a dedicated script to invoke mypy and also set the env var MYPY_PATH from computed values for the legate install. But if anyone has any other ideas, I would love to hear them.

[bryevdv]

Working on linalg now and running into issues with the code that uses legate.core directly. I think actually we will have to simply check both together, in order to check cunumeric:

mypy ../legate.core/install38/lib/python3.8/site-packages/legate /home/bryan/work/legate.core/typings/ cunumeric

I tried several approaches with MYPYPATH and it was just not picking up imports and types correctly.

Anyway, I will stop this PR for now as a first step.

[bryevdv]

Once #387 is merged, then linalg also works, with either of these invocations:

~/work/cunumeric bryanv/mypy*
dev38 ❯ mypy ../legate.core/legate /home/bryan/work/legate.core/typings/ cunumeric
Success: no issues found in 79 source files

~/work/cunumeric bryanv/mypy*
dev38 ❯ mypy ../legate.core/install38/lib/python3.8/site-packages/legate /home/bryan/work/legate.core/typings/ cunumeric
Success: no issues found in 79 source files

I assume passing the installed version will be more CI-friendly? If so then I will add a script to wrap the mypy invocation to include this.

[manopapad]

This is because legate is not actually installed in the site-packages for the Python that is executing mypy. I think probably the only solution is a dedicated script to invoke mypy and also set the env var MYPY_PATH from computed values for the legate install. But if anyone has any other ideas, I would love to hear them.

We could just bite the bullet and update our setup process to always install legate/cunumeric properly in the currently active virtual environment, instead of using a custom directory that needs to be passed everywhere. We will need to do this anyway eventually, as the setuptools deprecation warnings keep telling us.

[bryevdv]

We could just bite the bullet and update our setup process to always install legate/cunumeric properly in the currently active virtual environment, instead of using a custom directory that needs to be passed everywhere. We will need to do this anyway eventually, as the setuptools deprecation warnings keep telling us.

I think that would be wonderful but also sounds like a bit of an endeavor. I guess I would not hold up this PR for that, since a wrapper script is a simple solution for the immediate term.

[bryevdv]

OK I removed the mypy_path config. I don't want to add a script just yet until the cmake PRs are merged, since the mechanism to discover the legate install will be different. For now, run e.g.

mypy ../legate.core/install38/lib/python3.8/site-packages/legate /home/bryan/work/legate.core/typings/ cunumeric

I guess we will actually need to find a place to install those typings if we want to avoid referencing the source tree for legate (or maybe that's fine).

[bryevdv]

whoops, introduced two minor issues. Should go green now (all tests pass locally eager/gpu/cpu)

[bryevdv]

OK it was also easy to add cunumeric.logic and at that point also simplify the config in pyproject.toml The rest are better left to a follow-on PR.

[bryevdv]

Merge conflict is resolved.

[bryevdv]

Diff here was simply removing the superfluous else.