typeddjango / django-stubs

PEP-484 stubs for Django
MIT License
1.61k stars 452 forks source link

Could not resolve manager type for "core.models.FooModel.objects" [django-manager-missing] #1023

Open MartinThoma opened 2 years ago

MartinThoma commented 2 years ago

Bug report

I've updated django-stubs-ext from 0.4.0 to 0.5.0 and got a lof of error messages from mypy. Before, mypy didn't complain

There might actually be nothing wrong with django-stubs, but maybe I need to add a type annotation. The problem is that I have no idea what I need to change.

The code has many unit tests. It's very unlikely that all of those locations mypy now complains about actually have issues that would prevent proper code execution.

What's wrong

mypy shows several django-manager-missing errors.

How is that should be

No mypy errors shown

System information

jose-reveni commented 2 years ago

I have been getting the same error and I think it might be related to #1022

flaeppe commented 2 years ago

I wouldn't directly say it's related to #1022, unless you're seeing that error too.

The error you're seeing was intentionally introduced in #999.

I'd start with investigating the types for your model managers. I think manager names are outputted in the errors you're seeing?

Could you display how you set up one of those managers generating the error?

MartinThoma commented 2 years ago

I didn't setup any manager explicitly for those models.

I create those models like this:

from django.db import models
import uuid

class Base(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)

class FooModel(Base):
    foo = models.CharField(max_length=100)
    bar = models.BooleanField()

And I use it like this: FooModel.objects.all().

There is, of course, way more going on, but that is the gist of it. I can try to make a minimal example with pinned dependencies some time this week if that helps.

flaeppe commented 2 years ago

Interesting, I'm pretty certain we have test cases covering non-explicit managers.

But I'll double check that.

A minimal example would be helpful too!

aleksanb commented 2 years ago

UUID might hack itself onto the base manager of models that use it, perhaps? Similar to the way django money was found to be behaving.

MartinThoma commented 2 years ago

I actually also use Django money. I thought it was not related :thinking:

flaeppe commented 2 years ago

Hm, one important lead would be what the type the manager is during runtime.

@MartinThoma since it's an implicit manager. Could you investigate what type(FooModel.objects) outputs?

flaeppe commented 2 years ago

I actually also use Django money. I thought it was not related :thinking:

Then it could be related to https://github.com/typeddjango/django-stubs/pull/993#issuecomment-1155151881

MartinThoma commented 2 years ago

Using the interactive shell:

>>> type(FooModel.objects)
djmoney.models.managers.money_manager.<locals>.MoneyManager
MartinThoma commented 2 years ago

I'm using django-money==3.0.0

flaeppe commented 2 years ago

Then it's definitely related to https://github.com/typeddjango/django-stubs/pull/993#issuecomment-1155151881 and django-money not exporting types.

I'm afraid it's not much to do other than ignoring the error until django-money starts to export types. At least as far as I'm aware

rr- commented 2 years ago

Our case is something like

class UUIDPrimaryKeyAbstractModel(models.Model):
    id = models.UUIDField(primary_key=True, unique=True, default=uuid.uuid4, editable=False)

    class Meta:
        abstract = True

class Foo(UUIDPrimaryKeyAbstractModel):
    pass

class Bar(UUIDPrimaryKeyAbstractModel):
    foo = models.ForeignKey(Foo, on_delete=models.CASCADE)

No django-money.

tilsche commented 2 years ago

I would like to add that we have the same issue with another untyped library that provides Model base classes.

Since it is not possible to suppress the error in mypy and there seems to be no other workaround, this is a complete blocker for us to switch to 1.12.0

martin056 commented 2 years ago

Hi, I'm also using django-money==3.0.0 and I bump into the same problem. It actually blocks me from updating not only the django-stubs version but the mypy one as well.

Is there any temporary workaround?

sondrelg commented 2 years ago

Then it's definitely related to #993 (comment) and django-money not exporting types.

I'm afraid it's not much to do other than ignoring the error until django-money starts to export types. At least as far as I'm aware

I tried forking the repo and adding the required py.typed. That didn't immediately work, so I tried adding some strategic type hints, but no luck.

After looking at how django-money overrides managers though, I'm not confident this actually can be fixed by exporting types.

Essentially what django-money does is subscribe to the class_prepared signal, so it receives all the django models in the project on startup, here. Then, if the model has a money-field, it dynamically patches the manager here, like this.

This, to me, seems impossible to type hint. Do you agree, or am I missing something? Hoping for the latter :crossed_fingers: :slightly_smiling_face:

mschoettle commented 1 year ago

I am running into this problem when using django-modeltranslation.

type(Model.objects) returns <class 'modeltranslation.manager.MultilingualManager'>.

Is there any workaround that I could do or is this something that would need to be fixed within django-modeltranslation?

HitLuca commented 1 year ago

Having the same issue as @mschoettle , using django-modeltranslation and getting the django-manager-missing error

browniebroke commented 1 year ago

Same issue with django-modeltrans. Ive opened an issue there but I just found this one.

In case it helps, I've got a minimal project reproducing the issue with that library: https://github.com/browniebroke/modeltrans-mypy-bug

browser-bug commented 5 months ago

I'm sorry for the bump but are there any updates or improvements on this matter? I've just encountered this issue with django-notifications and it doesn't seem to be any right solution which is not an hacky type annotation on the referenced models.

haard commented 4 months ago

Same issue with django-taggit

Would it be possible to add disable-error-code config to django-stubs[-ext]?

emilte commented 3 months ago

Same here. It seems to trigger with only a subclassed Model too. I wrote my own extended Model class to abstract a few common traits.

ebk46 commented 2 months ago

Any updates on this? Is there a workaround? We're hitting this issue with a model inheriting 2 of our own abstract classes and no untyped/mistyped third party packages in the chain. I tried adding the type hints to the model to represent the relationship but that doesn't seem to work.

danjac commented 2 months ago

Also hitting this issue: originally I thought problem was inheriting from model_utils.TimeStampedModel but after removing this base class the issue persists. I have also tried the workaround with django_stubs_ext.db.models.manager.RelatedManager. Currently at least with 5.0.4 it appears there is no way to use this library with ForeignKey relations in Django?

pheki commented 1 month ago

If anyone doesn't know: you can ignore this error by adding a # type: ignore[django-manager-missing] to the lines that are reported on mypy (usually the class declaration line in a class that is the target of a ForeignKey from a model with untyped / dinamically added managers as it happens on the reverse relation).

Currently at least with 5.0.4 it appears there is no way to use this library with ForeignKey relations in Django?

I'm still on 4.0.0, but for me ForeignKey relations only trigger this issue when the model you're creating the ForeignKey from has a field has a dinamically added / untyped manager. Counterintuitively, the issue is not caused by managers on the model that's the target the error is reported on. AFAIK the workaround is to add a type ignore as specified above.