Resolve configured AUTH_USER_MODEL with a get_type_analyze_hook
#2335
Conversation
|
Hm, we should do the same thing for |
|
Not sure why this fails. It passes locally for me |
|
Right, I think I figured it out. The test needs to invalidate cache or something, because if |
mypy_django_plugin/main.py
Outdated
| extra_data = {} | ||
| if ctx.id == "django.contrib.auth": | ||
| extra_data["AUTH_USER_MODEL"] = self.django_context.settings.AUTH_USER_MODEL | ||
| return self.plugin_config.to_json(extra_data) |
There was a problem hiding this comment.
Now we get "implicit" cache tainting on django.contrib.auth, and thus authenticate and friends if AUTH_USER_MODEL changes.
There might be other modules we want to add some extra config data to. Not sure though
|
Actually, I want to try out a better idea. A bit bigger but if it works it would be nice. This: #1058 (comment) |
It's nothing special really. We declare a `TypeAlias` in the pyi, thus getting a fullname, somewhere under `django.contrib.auth`. We then build a hook for that fullname. And the hook simulates what `django.contrib.auth.get_user_model` does The alias is set up to point to `AbstractBaseUser`, so for a type checker other than mypy nothing should've changed
|
I think I got it working. It should now improve and resolve multiple other stuff as well. |
flaeppe
changed the title
django.contrib.auth.authenticateAUTH_USER_MODEL with a get_type_analyze_hook
…_type_analyze_hook`
… a `get_type_analyze_hook`
I'm currently on garden leave from my previous job, but I still have my work laptop and access to the codebase so I can try to give this a spin. It's been a while since I touched that project though, so I'm not sure what state it is in with regards to mypy updates etc. Otherwise I no longer have any large Django projects that I'm working on. |
|
Thank you, would be awesome if you had the possibility to run against something we've tried previously. |
flaeppe
added
the
release notes reminder
I just gave it a go and I'm not seeing any crashes at least. There's a ton of new errors though. Randomly looking at them there seems to be a lot of errors resolving return types of querysets. That might be from something else between 5.0.2 and laster master though. |
|
Cool, thank you for trying it out and reporting back! |
flaeppe
removed
the
release notes reminder
| # This is our "placeholder" type the mypy plugin refines to configured 'AUTH_USER_MODEL' | ||
| # wherever it is used as a type. The most recognised example of this is (probably) | ||
| # `HttpRequest.user` | ||
| _UserModel: TypeAlias = AbstractBaseUser # noqa: PYI047 |
There was a problem hiding this comment.
I know this is just a placeholder, and was chosen to not change things, but should this not be AbstractUser not AbstractBaseUser?
Looking at Django the difference between the two would be:
For me I'm seeing that is_superuser is not defined and that's because it's checking against AbstractBaseUser.
Anyways, just asking since I'm assuming you know the hierarchy a little better than I do, and I will continue trying to figure out why my customized plugin might not be resolving the user model.
`PyTypeHintProvider` allows providing type hints for resolved elements before the main logic of `PyTypingTypeProvider`. See an example of `django-stubs`: typeddjango/django-stubs#2335. `_UserModel` type might be replaced with a custom user model, provided in `settings.py` (`AUTH_USER_MODEL`). GitOrigin-RevId: 986fb91c800be3ccfbc002c73c673896efec8a1a
It's nothing special really. We declare a
TypeAliasin the pyi, thus getting a fullname, somewhere underdjango.contrib.auth. We then build a type analyze hook for that fullname. And the hook simulates whatdjango.contrib.auth.get_user_modeldoesThe alias is set up to point to
AbstractBaseUser, so for a type checker other than mypy nothing should've changedThe implementation idea directly taken from: #1058 (comment). Thanks for the suggestion.
Related issues
user_passes_testshould take inAUTH_USER_MODEL#1058get_user_model_hookraisesLookupErrorwithoutauthapp #1380