Cannot compile Mypy with Mypyc

[agriyakhetarpal]

Bug Report

Hi there, I'm unable to compile Mypy with Mypyc (i.e., with MYPY_USE_MYPYC enabled) using the standard pip install -e . invocation – I first noticed this in pyodide/pyodide#5124 where it's breaking our CI, but it happens locally on conventional targets on a macOS device, and in CI as well: https://github.com/agriyakhetarpal/mypy/actions/runs/11692836659/job/32563074252

To Reproduce

In a terminal, run the following command:

MYPY_USE_MYPYC=1 pip install -e .

Expected Behavior

The expected behaviour is that Mypy compiles with Mypyc.

Actual Behavior

I think it's a setuptools problem – here's an excerpt from the logs:

mypyc/build.py:280: error: Argument "sources" to "Extension" has incompatible type "list[str]"; expected "list[str | PathLike[str]]"  [arg-type]
mypyc/build.py:280: note: "List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
mypyc/build.py:280: note: Consider using "Sequence" instead, which is covariant
mypyc/build.py:316: error: Argument "sources" to "Extension" has incompatible type "list[str]"; expected "list[str | PathLike[str]]"  [arg-type]
mypyc/build.py:316: note: "List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
mypyc/build.py:316: note: Consider using "Sequence" instead, which is covariant

I haven't had a chance to bisect so far. I don't see a difference between the dependencies downloaded yesterday versus those downloaded today, either.

Your Environment

• Mypy version used: master branch/development version (and the latest release version)
• Mypy command-line flags: MYPY_USE_MYPYC set to 1
• Python version used: 3.12.6

Additional context

xref: pyodide/pyodide#5160

[brianschubert]

Looks potentially related to python/typeshed#12928, which changed sources: list[str] to sources: list[StrPath] in Extenion.__init__.

[hauntsaninja]

Yeah, I would pin to old types-setuptools for now

If that annotation can be loosened to Sequence it definitely should be, if not it should take list[str] | list[StrPath]. PR to typeshed welcome!

[agriyakhetarpal]

Yes, I think Sequence would be better, since the operation (building extension modules) only needs to read from the sequence, and not modify it. Am I correct in saying that I should modify the distutils stubs that setuptools derives from so that the derived one isn't more permissive?

I'm preparing a PR as we speak, but I'm not sure how to verify the change because it looks like typeshed is vendored in Mypy.

[hauntsaninja]

Thanks for voyaging across a few different projects to fix this! :-)

[Avasam]

python/typeshed#12958 has been merged !

[agriyakhetarpal]

Thank you for the prompt reviews and guidance! All I need to bring in the patch from python/typeshed#12958 to mypy/typeshed here in a PR and we can close this, right?

[agriyakhetarpal]

Never mind, the patch doesn't apply. There isn't a submodule either, it's vendored by copying the source. The fix is not obvious to me at the time of writing :)

[JelleZijlstra]

There is a workflow (https://github.com/python/mypy/actions/workflows/sync_typeshed.yml) that syncs typeshed into this repo. I triggered it manually just now. It should create a PR with your changes.

However, your PR touched both the distutils stubs (which are part of the stdlib) and the setuptools stubs (which are a third-party package). Mypy vendors only the former. For the latter, we'll automatically upload a new package within a day to https://pypi.org/project/types-setuptools/ . I believe mypy doesn't pin that package, so once it's on PyPI, no further work should be required.

[agriyakhetarpal]

I think I can close this, since types-setuptools has a new release as mentioned and our CI pipelines are passing again. Cross-linking #18114 for the update.