sbdchd / django-types

:doughnut: Type stubs for Django
MIT License
187 stars 62 forks source link

New release for compatibility with pyright 1.1.324 #194

Open voidus opened 12 months ago

voidus commented 12 months ago

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 commented 12 months ago

Yup, that would be great!

sbdchd commented 12 months ago

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

panupong-puttarathamrongkul commented 12 months ago

Confirm that it has been resolved.

kylemacfarlane commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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, https://github.com/sbdchd/django-types/commit/06da6da7fce4d8bc944e74b403e470ee1eacb57e, and even that fails :thinking:

kylemacfarlane commented 11 months ago

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 commented 10 months ago

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 commented 8 months ago

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 commented 7 months ago

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

The comments in https://github.com/microsoft/pyright/issues/5792#issuecomment-1690520091 and https://github.com/sbdchd/django-types/pull/181#issuecomment-1761534369 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, https://github.com/sbdchd/django-types/issues/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 commented 7 months ago

yeah makes sense to add to the readme!