django-types icon indicating copy to clipboard operation
django-types copied to clipboard

New release for compatibility with pyright 1.1.324

Open voidus opened this issue 1 year ago • 13 comments

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.

voidus avatar Sep 21 '23 13:09 voidus

Yup, that would be great!

paulzakin avatar Sep 21 '23 19:09 paulzakin

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

sbdchd avatar Sep 22 '23 00:09 sbdchd

Confirm that it has been resolved.

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?

kylemacfarlane avatar Oct 07 '23 21:10 kylemacfarlane

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.

simensol avatar Oct 10 '23 07:10 simensol

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?

kylemacfarlane avatar Oct 13 '23 10:10 kylemacfarlane

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

EDIT:

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

simensol avatar Oct 13 '23 10:10 simensol

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:

JakobGM avatar Oct 13 '23 12:10 JakobGM

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.

kylemacfarlane avatar Oct 13 '23 17:10 kylemacfarlane

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.

simensol avatar Nov 06 '23 13:11 simensol

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

jellis18 avatar Dec 24 '23 14:12 jellis18

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?

simensol avatar Jan 30 '24 14:01 simensol

yeah makes sense to add to the readme!

sbdchd avatar Feb 03 '24 00:02 sbdchd