Conversation
This way parallel checking is available in the default install (as an experimental feature in mypy 2.0). We will keep ast-serialize backward compatible. By dropping the upper version bound, can avoid some minor friction when updating ast-serialize version to 1.x. Also `pip install mypy[native-parser]` is no longer supported, as it's redundant now.
ilevkivskyi
left a comment
There was a problem hiding this comment.
Not 100% sure about removing upper bound, I would feel safer knowing that we have an option to make a breaking change. But not strongly opposed to this either.
Also have a suggestion on dependency group, don't want to penalize people who actually tried the native parser.
| reports = ["lxml"] | ||
| install-types = ["pip"] | ||
| faster-cache = ["orjson"] | ||
| native-parser = ["ast-serialize>=0.2.0,<1.0.0"] |
There was a problem hiding this comment.
Maybe make it an empty list, to not break builds for brave people who actually tried this?
There was a problem hiding this comment.
I realised recently when removing the python2 extra that this doesn't actually break builds, it just issues a warning
This comment has been minimized.
This comment has been minimized.
Ok, we can keep the upper bound. We can remove it one or two mypy releases before we publish ast-serialize 1.0, so that there's a Window when both pre-1.0 and post-1.0 versions work. |
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
This way parallel checking is available in the default install (as an experimental feature in mypy 2.0).
We'll still support
pip install mypy[native-parser]as a no-op for backward compat.