Fix partially analyzed settings module

[PIG208]

I have made things!

For modules django.http and django.http.request, we manually add
dependency for the module containing AUTH_USER_MODEL for mypy to
resolve first.

This potentially adds cyclic dependency when the models module contains
a reference to django.conf, and the settings depend on any modules that
rely on django.http or django.http.request. At this point, the settings module is
only partially analyzed. The symbol table is populated (so top-level settings are
accessible by the name), but the types have not been inferred.

Removing this dependency of django.http and django.http.request works. But
if the settings module also depends on django.contrib.auth, this still breaks.

This can potentially break the refined type for request.user, which does depend
on AUTH_USER_MODEL being available beforehand. This implicit dependency
still needs to be somehow established.

So, until these issues are addressed, this fix is not final.

Related issues

• Closes Type from settings not correctly loaded in a model #312
• Refs Type from settings not correctly loaded in a model #312

[andersk]

But if the settings module also depends on django.contrib.auth, this still breaks.

That might not be a problem. My understanding is that a settings module is not supposed to have any dependencies on Django. That’s why AUTH_USER_MODEL is a string, for example.

[PIG208]

Yes. Essentially the problem we want to solve here is the cyclic dependency that is not supposed to emerge from the settings.

[andersk]

Hmm. Maybe my test case, and by extension the Zulip code it originated from, is just wrong for that reason.

[PIG208]

It is possible that this dependency is inevitable because it is from django_stubs_ext, which needs to be imported into the settings module. So probably we can fix that.

[andersk]

Maybe the application’s __init__.py is a better place for the django_stubs_ext.monkeypatch()? (If so, the documentation should be adjusted.)

[PIG208]

I ran this fix in Zulip. The error does not go away unless this get_user_model dependency as well as those for defined_model_classes (models referred via ForeignKeys) get removed completely. It appears that there are more ways to trigger this error through adding depdencies.

[andersk]

I got it working by breaking a bunch of import cycles in Zulip (zulip/zulip#23040), and moving django_stubs_ext.monkeypatch() to zerver/__init__.py.

To make this solution robust, ideally we’d replace this fallback to value.__class__ with an error, so that we’ll see the mistake if anyone tries to reintroduce such a cycle.

• Disable fallback to runtime types for Django settings #1163

[sobolevn]

Instead we merged #1163

Thanks for working on this!