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

[MartinThoma]

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

• OS: Ubuntu
• python version: 3.8
• django version: 3.2
• mypy version: 0.942
• django-stubs version: 1.12.0
• django-stubs-ext version: 0.5.0

[jose-reveni]

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

[flaeppe]

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]

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]

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]

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]

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

[flaeppe]

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]

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

Then it could be related to #993 (comment)

[MartinThoma]

Using the interactive shell:

>>> type(FooModel.objects)
djmoney.models.managers.money_manager.<locals>.MoneyManager

[MartinThoma]

I'm using django-money==3.0.0

[flaeppe]

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

[rr-]

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]

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