Open Alexerson opened 1 month ago
If I understand you correctly you can reproduce with the code you have? Essentially that your code triggers a regression between the versions?
Could you perhaps run a git bisect
between 5.0.2 and 5.0.3 to pin point which commit introduced the issue?
You could also try out master
to see if the issue exists there too.
Correct. My next plan was indeed to do a git bisect
but didn’t have plan to complete. Will do (hopefully) today.
I'm having the same issue fwiw, it starts like this:
Then it lists a bunch of my files, starting with this one:
from __future__ import annotations
from enum import Enum
from typing import TYPE_CHECKING, TypeVar
if TYPE_CHECKING:
from pydantic import BaseModel
from foo import FooRequest
from bar import BaseBar
from baz import BaseBaz
BaseModelT = TypeVar("BaseModelT", bound="BaseModel")
BaseBarT = TypeVar("BaseBarT", bound="BaseBarModel", covariant=True)
BaseBazT = TypeVar("BaseBazT", bound="BaseBaz", covariant=True)
EnumT = TypeVar("EnumT", bound=Enum)
FooRequestT = TypeVar("FooRequestT", bound="FooRequest")
(Redacted model names, apologies.)
My best guess is that this used to barely work, and now is no longer working? Or it could be a red herring. 🤷
Sorry, I didn’t get the time to finish my explorations. Also, it’s a weird bug, because changing versions sometimes give me bugs with different configurations… The bug might be in mypy and not django-stubs in the end, not sure... I’ll try to find more time this week to keep exploring.
Bisect complete:
git bisect start
# status: waiting for both good and bad commits
# bad: [ffcebb3f0a71c4a2c3fd5038d29b3a5bcbf73248] Add django 5.1 to the test matrix and add its classifier (#2380)
git bisect bad ffcebb3f0a71c4a2c3fd5038d29b3a5bcbf73248
# status: waiting for good commit(s), bad commit known
# good: [5118c5dfbe99504e1cca57ea00bf38bd14014e4f] Bump `django-stubs-ext` dependency to latest (#2186)
git bisect good 5118c5dfbe99504e1cca57ea00bf38bd14014e4f
# bad: [d60e31ed0ac4e4115f9ef20041521c201391d592] Prepare for a release `5.0.4` (#2285)
git bisect bad d60e31ed0ac4e4115f9ef20041521c201391d592
# good: [3830fa9b76901c0fb76cd28aa900349d1ead344c] fix handling of explicit `objects` annotation (#2241)
git bisect good 3830fa9b76901c0fb76cd28aa900349d1ead344c
# good: [b2b1afac196e622ec725248cad1c22a6557253d0] Allow single generic param for Field in ForeignKey (#2261)
git bisect good b2b1afac196e622ec725248cad1c22a6557253d0
# skip: [d747285f9597eb0942cd2e5049ed2cec6a0ac90a] Improve stackoverflow link
git bisect skip d747285f9597eb0942cd2e5049ed2cec6a0ac90a
# bad: [59ebe6f1523c4d321b9e5ecba6c6458ace813489] fill QuerySet generics using the manager's model type (#2281)
git bisect bad 59ebe6f1523c4d321b9e5ecba6c6458ace813489
# bad: [0022c598d478d5e6714e21b103ccf408b0a4ba40] Bump pyright from 1.1.372 to 1.1.373 (#2273)
git bisect bad 0022c598d478d5e6714e21b103ccf408b0a4ba40
# bad: [94846987415e16f508df73ff7439993bbf2e41e3] add `Path` type argument to tuple returned by `get_app_template_dirs` (#2266)
git bisect bad 94846987415e16f508df73ff7439993bbf2e41e3
# bad: [3f0da4f9d28fcaa20cb6d9c7d71b589dd46722f7] Bump pyright from 1.1.371 to 1.1.372 (#2264)
git bisect bad 3f0da4f9d28fcaa20cb6d9c7d71b589dd46722f7
# bad: [ac36393ba31ebafbd436b140576d8f828d8c7474] Unify plugin check for model type info (#2263)
git bisect bad ac36393ba31ebafbd436b140576d8f828d8c7474
# first bad commit: [ac36393ba31ebafbd436b140576d8f828d8c7474] Unify plugin check for model type info (#2263)
It seems that the issue started with ac36393ba31ebafbd436b140576d8f828d8c7474, though when I revert it on top of master
(currently ffcebb3f0a71c4a2c3fd5038d29b3a5bcbf73248) I still see the same issue. It could be an issue with my testing methodology, as I'm doing pip install git+file:///tmp/django-stubs
and seeing some "requirement already satisfied":
Collecting git+file:/tmp/django-stubs
Cloning file:///tmp/django-stubs to /tmp/pip-req-build-1ha3uzw8
Running command git clone --filter=blob:none --quiet file:///tmp/django-stubs /tmp/pip-req-build-1ha3uzw8
warning: filtering not recognized by server, ignoring
Resolved file:///tmp/django-stubs to commit 496df6a7d3fd78c93739974892ccbf64fbc456a2
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: django in /.venv/lib/python3.12/site-packages (from django-stubs==5.1.0) (5.1.1)
Requirement already satisfied: asgiref in /.venv/lib/python3.12/site-packages (from django-stubs==5.1.0) (3.8.1)
Requirement already satisfied: django-stubs-ext>=5.1.0 in /.venv/lib/python3.12/site-packages (from django-stubs==5.1.0) (5.1.0)
Requirement already satisfied: typing-extensions>=4.11.0 in /.venv/lib/python3.12/site-packages (from django-stubs==5.1.0) (4.12.2)
Requirement already satisfied: types-PyYAML in /.venv/lib/python3.12/site-packages (from django-stubs==5.1.0) (6.0.12.20240917)
Requirement already satisfied: sqlparse>=0.3.1 in /.venv/lib/python3.12/site-packages (from django->django-stubs==5.1.0) (0.5.1)
I'm testing with Mypy 1.11.2, in case that's helpful -- unless I'm making some mistakes, it looks to me like this is specific django-stubs[-ext].
Interesting, I just triggered the same bug when upgrading dependencies in CI, even though django-stubs and django-stubs-ext are pinned. The only relevant changes:
Odd, I wonder if the same problem was merged into DRF-stubs?
Ok, so I spent some time trying that out again this morning.
9a5ef9acfa37bc5a5e7338c1bad693a8bb19e25d seems to be the issue. Reverting it on top of master fixes the issue.
I will read more about this commit and the issue mentioned in the comment to see if I can see what’s possible.
Finding that the problematic commit was about managers and from_queryset
, I looked at our codebase and I was able to find a manager that depends on a queryset that depends on a model that depends on the manager.
I’m trying to write a minimal reproduction, but I have a workaround in our case.
I looked at our codebase and I was able to find a manager that depends on a queryset that depends on a model that depends on the manager.
Do you mean something like:
class MyQuerySet(QuerySet[MyModel]):
...
MyManager = Manager.from_queryset(MyQuerySet)
class MyModel(Model):
objects = MyManager()
Yes. More specifically, something like (but more complicated, because I’m inheriting from custom QuerySet and Manager):
class MyQuerySet(models.QuerySet):
...
class MyManager(models.Manager):
...
class MyModel(models.Model):
objects = MyManager['MyModel'].from_queryset(MyQuerySet)
...
I removed the ['MyModel']
in the objects =
line and added it to the MyQuerySet
and it seems to work fine (it’s even showing me more real type errors in other places of the codebase). It was even more convoluted to be honest. I feel whoever wrote that code back in the day (= most likely me…) didn’t quite understand what it was doing.
It’s still unexpected that it would break because it used to be fine, but I’m not sure it’s a bug really. (I’m not saying "work", because I feel mypy was just ignoring some stuff that he’s now understanding and properly checking).
Thanks! Do you have any advice on finding the culprit? The stack trace is huge, and I couldn't make sense of it, and I can't find anywhere that I'm doing anything likeobjects = MyManager['MyModel'].from_queryset(MyQuerySet)
.
Bug report
What's wrong
When running django-stubs 5.0.2, mypy goes through without error. But when updating django-stubs to 5.0.3, I’m getting the following error:
error: INTERNAL ERROR: maximum semantic analysis iteration count reached
.The traceback is huge, and not really helping, so my next step is to have a minimal reproduction, but I wanted to raise the bug in case someone else is running into this as well. I’ll also try to review what’s happening between the 2 versions to understand where the issue can be.
System information
python
version:django
version: 5.0.9 (but same error with 5.1.1)mypy
version: 1.11.2 (but same error with 1.10.1)django-stubs
version: 5.0.3django-stubs-ext
version: 5.0.3It works fine with:
django
version 5.1.1mypy
version 1.11.2django-stubs
version 5.0.2django-stubs-ext
version 5.0.2