On 2/18/23 10:27, Markus Armbruster wrote:
This one is valid. Still, it's a "want", not a "must have". If it was
a hard "must have", then CentOS 8 support would be in trouble: no mypy
out of the box, as far as I can tell.
Right, and in fact this is by design: these tools move too fast for a
version packaged for RHEL8 in 2017 to be useful.
(A) Commit to keeping mypy happy for all versions of mypy provided by
any supported build host
(B) Pick a single mypy version
Developers have to run this mypy version, or else punt to
maintainers. We'll naturally pick a mypy version the maintainers
are happy to run, so no need for them to punt to CI. We can exploit
the full typing power of that mypy version. We don't have to work
around issues older versions may have.
Developers unable to run this mypy version locally get delayed
feedback. Affects the intersection of "people working on Python
code we check with mypy" and "people developing exclusively on older
hosts". If we further intersect with "people doing so on a somewhat
regular basis", I posit we get the empty set.
I think (A) is pretty much all downsides. I like (B), but could be too
rigid in practice.
I think (B) is feasible. Right now those developers can use CI and in
the future we'll have the ability to automatically set up a virtual
environment for them.
Paolo
