Will mypy work universally again? Or is the list of supported platforms now more or less set in stone?

[pajod]

Documentation

ERROR: Could not find a version that satisfies the requirement librt>=0.10.0; platform_python_implementation != "PyPy" (from mypy) (from versions: 0.0.1)

Changelog has been less than on the nose on dropped platform support lately, so.. what is changed about that?

Mypy now has an extra dependency on the librt PyPI package

I believe in 1.19 librt became a hard dependency (ImportError) even though as of mypy 2.0.0 it still works without it (sans --incremental). (I created a stub librt/internal.py file; that was all I needed to be able to type check after upgrade, so I know it was not necessary.)

There are still some minor semantic differences between parallel and non-parallel modes, which we will be fixing in future mypy releases.

Relatedly, it looks like the more complex non-python dependency ast-serialize is also not strictly needed right now (other than for --native-parser), but current documentation does clarify whether that is just temporarily so (until parsers reach feature parity). Should users expect that some future mypy version will hard-depend on OpenAI-owned code?

Is there a point in either releasing a stub universal python wheel or try/excepting the optional features so mypy remains usable on platforms that cannot use either or both new non-python dependencies?
Or should the Changelog just enumerate positively what arch/platform list now remain, plus maybe an update to the Does it run on PyPy? section?

[ilevkivskyi]

The plan is to make native parser the default, and ultimately the only parser at some point. Most likely already this year. This means that mypy will not work without both librt and ast-serialize.

That said we still hope that it will possible to run mypy on PyPy. I know that this is theoretically possible (for example IIUC one can run NumPy on PyPy), it is just that we don't have bandwidth to prioritize this, this is why keep #20329 open.

Regarding the dependency on "OpenAI-owned code", IIUC you mean few Ruff crates needed to compile ast-serialize? If yes, then I would not worry about that. They don't really own it, that code is licensed under MIT license which means we can easily fork it at any moment if any problems arise. Moreover, hopefully we will vendor that code soon, see mypyc/ast_serialize#49, so that mypy will continue to be packaged for Debian and other distros.