Closed a-recknagel closed 4 years ago
Current workflow file uses a matrix for python versions, which gets executed by actions/setup-python. As soon as they adapt newer pypy builds (https://github.com/actions/setup-python/issues/16), we can just extend the matrix to address this issue.
Added https://github.com/a-recknagel/stenotype/tree/ar/add_pypy to test wether pypy3 is on 3.6 already, and turns out it is. But the testsuite can't finish because c-headers are missing for the typed-ast
build: https://github.com/a-recknagel/stenotype/runs/337536249
.. and it might never build against pypy until 3.8 when it's part of the stdlib https://github.com/python/typed_ast/issues/97#issuecomment-484337454
That feels to me as if we can't support usage with pypy for now @maxfischer2781, or am I missing something?
The typed-ast
is a dependency of mypy
and black
only -- stenotype itself doesn't need it. I know this problem from other projects, for which we had to disable the two static checkers in PyPy CI builds. (There is https://github.com/psf/black/pull/1172 which might enable black
for PyPy, but I see nill for mypy
.)
For PyPy CI runs to check our own code, either running the tools with a plain CPython or disabling them outright is fine. As long as any CI run calls the tools, we're good.
As for functionality, we obviously cannot support mypy
run through PyPy, because there is no such thing. This doesn't hurt much, because PyPy's JIT isn't optimal for that anyway (mypyd
might be another story?). However, types are used for more than just mypy
so I would like to support as much as possible, and keep the option for full PyPy support with PyPy3.8.
Most importantly, we should support regular annotations at runtime on PyPy. That is, everything that ends up as some __annotations__
. These are inspectable/useable by code, e.g. by functools.singledispatch
. typed-ast
does not fall into that category, so no harm there.
The TLDR is: Disable mypy
and black
on our own codebase in the PyPy CI. Assume that all unit-tests have to pass for PyPy as well. Tests that are restricted to mypy
interoperability could be excluded individually if we're certain they cannot run.
Alright, that makes a lot of sense. I'll need to restructure the CI a bit then, because now it starts off with poetry install
, which just installs all dev-requirements.
I remembered a cute snipped that lets us declare tests as mypy-only like this: https://github.com/a-recknagel/stenotype/blob/0a8f849890e5d833934b7fa33a4d481611595c4d/tests/test_util.py#L18
If marked like that, a test will not run as part of the normal suite, and only if pytest is called with pytest --mypy
.
Since the tests run with pypy as well, I'd consider it supported after #31 is merged (which I'll do in a minute).
Some people like to use pypy rather than cpython, so including it into the test suite as early as possible means that we can be compatible from the get go.
Since this project will likely use hacks to make the import hook happen it feels a bit more urgent than normal.