Tests: Add test case for settings import cycle

[intgr]

Add a testcase that demonstrates the 'Import cycle from Django settings module prevents type inference' error and ensures it doesn't regress.

Related:

• Fixing 'Import cycle from Django settings module prevents type inference' #2097

[flaeppe]

Nice that we now get coverage for this case. But I'm a bit baffled, since I would have liked mypy to figure this out instead of us.

If I set up a similar case with a cyclic import(see below). Mypy is able to figure out all types without any issues. I might be wrong here but what I'm saying is that it could be an improvement if we were able to tell mypy to behave like my case below. I don't know how or if it's even possible, since it probably depends on at what stage the plugin gets involved, but since mypy is able to solve it perhaps there's a possibility for the plugin to poke mypy in the direction to behave like it does to figure out the below case.

Our plugin being the one emitting the error isn't any serious issue really, since adding explicit types is a solution, decent as well. And an alternate approach might even be larger and more complex. I just wanted to lift the idea here.

Here's the cyclic case I was thinking about:

# a.py
from b import function_returning_int
VAL = function_returning_int()
reveal_type(VAL)

# b.py
import a

def test() -> None:
    reveal_type(a.VAL)

def function_returning_int() -> int:
    return 42

[intgr]

Agreed, it would be nice to solve this in plug-in code and avoid the circular import error entirely. But given that the work-around isn't complicated, it's not a high priority from my PoV.

[flaeppe]

It seems that returning a dependency with PRI_HIGH in get_additional_deps for django.conf.settings removes the error emitted in the test case added here.