New release for compatibility with pyright 1.1.324

[voidus]

pyright fixed how the resolve metaclass attributes in 1.1.324, which causes issues with the way MyModel.objects is declared here. In short, MyModel.objects will still be resolved as BaseManager[MyModel] even if objects was assigned a different manager.

This was fixed here, and it would be nice if the latest released django-types version would be compatible with the latest pyright version.

I'm not sure if it should be 0.18.0 or 0.17.1.

[paulzakin]

Yup, that would be great!

[sbdchd]

Should be all set -- I really need to automate the releases lol

[panupong-puttarathamrongkul]

Confirm that it has been resolved.

[kylemacfarlane]

I get this bug with pyright 1.1.330 and django-types 0.18.0 but not with 0.17.0. Why am I seemingly experiencing the opposite of what everyone else has described?

[simensol]

The only working combination of pyright and django-types for me, seems to be pyright==1.1.323 and django-types==0.17.0:

pip install pyright==1.1.323 django-types==0.17.0
pyright .
...
0 errors, 0 warnings, 0 informations

pip install pyright==1.1.323 django-types==0.18.0
pyright .
...
157 errors, 0 warnings, 0 informations

pip install pyright==1.1.324 django-types==0.17.0
pyright .
...
136 errors, 0 warnings, 0 informations

pip install pyright==1.1.324 django-types==0.18.0
pyright .
...
157 errors, 0 warnings, 0 informations

pip install pyright==1.1.330 django-types==0.17.0
pyright .
...
137 errors, 0 warnings, 0 informations

pip install pyright==1.1.330 django-types==0.18.0
pyright .
...
158 errors, 0 warnings, 0 informations

Since your types are shipped with Pylance, I also had to downgrade Pylance to fix this issues.

[kylemacfarlane]

Things get stranger. On MacOS I have the same problem as @simensol. Only 1.1.323 and 0.17.0 works.

But on WSL any version of pyright + 0.17.0 seems to work.

I can find no combination on either OS that works with 0.18.0. But others seem to be implying 0.18.0 does work for them.

Could it be the Node version or some other dependency?

[simensol]

I'm on macOS (v13.5.2). However, I'm developing inside VSCode devcontainers with UbuntuDebian.

EDIT:

> node -v
v18.18.0
> lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm

[JakobGM]

We are experiencing the same issue, being stuck on pyright==1.1.323 since AnyModel.objects has inferred type BaseManager[AnyModel] instead of OurCustomAnyModelManager on versions pyright>= 1.1.324 for both django-types==0.17.0 and django_types==0.18.0.

EDIT: Just tested with the latest revision of main now, 06da6da, and even that fails 🤔

[kylemacfarlane]

I figured out my WSL weirdness. Neovim's LSP server was using a Windows version of pyright 1.1.298 that was installed outside of WSL and available lower down the Linux PATH list. I don't know why it prefers that version, maybe it reads the PATH list backwards.

So now my issue is identical to everyone else's.

[simensol]

This is still an issue with django-types 0.19.1, preventing me from keeping Pyright and the VSC Pylance extension updated:

pip install pyright==1.1.334 django-types==0.19.1
pyright .
...
159 errors, 0 warnings, 0 informations

December 8th: Same issue with pyright==1.1.339.

[jellis18]

Does anyone here have an idea of how to fix this? I'm happy to do it but I'm not very familiar with the ecosystem here

[simensol]

I finally got django-types 0.19.1 to work with the latest Pyright version (1.1.336).

The comments in microsoft/pyright#5792 (comment) and #181 (comment) made me add types for my custom managers. When my custom managers went from untyped:

objects  = GroupManager()

to typed:

objects: ClassVar[GroupManager] = GroupManager()

most of the linting errors disappeared. I'm not sure if this will fix your issues @jellis18 @kylemacfarlane @JakobGM, but at least to me this issue is solved.

However, when my custom managers got typed, #226 was raised, so I have created a new issue for it.

Maybe the typing of custom managers should be documented in the readme, @sbdchd?

[sbdchd]

yeah makes sense to add to the readme!