Move mypy version upper bound to a [compatible-mypy] extra #979
Conversation
|
Since mypy does not provide any kind of backward-compat, I think it is safe to leave this bound. 🤔 |
|
They don’t guarantee plugin compatibility at this time, but they are making some effort—for example, python/mypy#11932. Plugin compatibility isn’t what motivated this upper bound in the first place, and doesn’t seem to be a frequent problem in practice. Meanwhile, for a project that’s interested in using django-stubs, I’d be more comfortable knowing that it won’t unnecessarily hold back other dependencies (as it currently would, since #973 hasn’t been released). I already pin all transitive dependencies with a lock file that I regularly update on my terms, so I can always decide to hold back mypy myself if something doesn’t work. Would you be more comfortable moving the upper bound to an extra, perhaps |
|
Hm, I like the |
andersk
changed the title
|
Cool, updated as such. |
Due to a bug in mypy 0.940 (typeddjango#870), we made two changes in typeddjango#871: • pinned mypy==0.931 in requirements.txt (for running our tests); • bounded mypy<0.940 in setup.py (for downstream users). After the mypy bug was quickly fixed upstream in 0.941, our setup.py bound has been repeatedly raised but not removed (typeddjango#886, typeddjango#939, typeddjango#973). The only changes in those commits have been to the precise wording of error messages expected in our tests. Those wording changes don’t impact compatibility for downstream users, so it should be safe to go back to allowing them to upgrade mypy independently. Since mypy doesn’t yet guarantee backwards compatibility in the plugin API (although in practice it has rarely been an issue), add a django-stubs[compatible-mypy] extra for users who prefer a known-good version of mypy even if it’s a little out of date. Signed-off-by: Anders Kaseorg <[email protected]>
…go#979) * Move mypy version upper bound to a [compatible-mypy] extra Due to a bug in mypy 0.940 (typeddjango#870), we made two changes in typeddjango#871: • pinned mypy==0.931 in requirements.txt (for running our tests); • bounded mypy<0.940 in setup.py (for downstream users). After the mypy bug was quickly fixed upstream in 0.941, our setup.py bound has been repeatedly raised but not removed (typeddjango#886, typeddjango#939, typeddjango#973). The only changes in those commits have been to the precise wording of error messages expected in our tests. Those wording changes don’t impact compatibility for downstream users, so it should be safe to go back to allowing them to upgrade mypy independently. Since mypy doesn’t yet guarantee backwards compatibility in the plugin API (although in practice it has rarely been an issue), add a django-stubs[compatible-mypy] extra for users who prefer a known-good version of mypy even if it’s a little out of date. Signed-off-by: Anders Kaseorg <[email protected]> * Update setup.py Co-authored-by: Nikita Sobolev <[email protected]>
Due to a bug in mypy 0.940 (#870), we made two changes in #871:
mypy==0.931inrequirements.txt(for running our tests);mypy<0.940insetup.py(for downstream users).After the mypy bug was quickly fixed upstream in 0.941, our
setup.pybound has been repeatedly raised but not removed (#886, #939, #973). The only changes in those commits have been to the precise wording of error messages expected in our tests. Those wording changes don’t impact compatibility for downstream users, so it should be safe to go back to allowing them to upgrade mypy independently.Since mypy doesn’t yet guarantee backwards compatibility in the plugin API (although in practice it has rarely been an issue), add a
django-stubs[compatible-mypy]extra for users who prefer a known-good version of mypy even if it’s a little out of date.