Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #870 #871

Merged
merged 3 commits into from
Mar 14, 2022
Merged

Fixes #870 #871

merged 3 commits into from
Mar 14, 2022

Conversation

himanshu-balasamanta
Copy link
Contributor

Changed the version requirement for mypy back to 0.931 in requirements.txt

Not sure if better methods of solving the issue is possible, just did what I saw that worked.

Signed-off-by: Himanshu-Balasamanta [email protected]

Signed-off-by: Himanshu-Balasamanta <[email protected]>
Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, also change setup.py

@himanshu-balasamanta
Copy link
Contributor Author

Changed. Kindly approve the workflow to be started if all looks good.

@himanshu-balasamanta
Copy link
Contributor Author

himanshu-balasamanta commented Mar 14, 2022

Hi, just to be sure.... Earlier mypy >=0.931 was allowed, now >=0.930 and < 0.940 is allowed.
This means 0.930 is included too now which it wasn't before.

@sobolevn sobolevn merged commit f9f6c82 into typeddjango:master Mar 14, 2022
@himanshu-balasamanta himanshu-balasamanta deleted the issue#870 branch March 14, 2022 19:28
andersk added a commit to andersk/django-stubs that referenced this pull request Jun 3, 2022
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.

Signed-off-by: Anders Kaseorg <[email protected]>
andersk added a commit to andersk/django-stubs that referenced this pull request Jun 3, 2022
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]>
andersk added a commit to andersk/django-stubs that referenced this pull request Jun 3, 2022
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]>
sobolevn added a commit that referenced this pull request Jun 4, 2022
* Move mypy version upper bound to a [compatible-mypy] extra

Due to a bug in mypy 0.940 (#870), we made two changes in #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 (#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.

Signed-off-by: Anders Kaseorg <[email protected]>

* Update setup.py

Co-authored-by: Nikita Sobolev <[email protected]>
PIG208 pushed a commit to PIG208/django-stubs that referenced this pull request Jun 13, 2022
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants