Add stubs for django.contrib.postgres.expressions

[flaeppe]

I'm a little bit surprised that this wasn't part of the allowlist_todo.txt. Suppose there might be some discrepancy in stubtest for missing modules?

[intgr]

See test output

django-stubs/contrib/postgres/expressions.pyi:9: error: Signature of "output_field" incompatible with supertype "BaseExpression"
django-stubs/contrib/postgres/expressions.pyi:9: note:      Superclass:
django-stubs/contrib/postgres/expressions.pyi:9: note:          Field[Any, Any]
django-stubs/contrib/postgres/expressions.pyi:9: note:      Subclass:
django-stubs/contrib/postgres/expressions.pyi:9: note:          cached_property[ArrayField[Any, Any]]

[flaeppe]

See test output

django-stubs/contrib/postgres/expressions.pyi:9: error: Signature of "output_field" incompatible with supertype "BaseExpression"
django-stubs/contrib/postgres/expressions.pyi:9: note:      Superclass:
django-stubs/contrib/postgres/expressions.pyi:9: note:          Field[Any, Any]
django-stubs/contrib/postgres/expressions.pyi:9: note:      Subclass:
django-stubs/contrib/postgres/expressions.pyi:9: note:          cached_property[ArrayField[Any, Any]]

Yeah, I saw that. It halfly depends on #1761. Unless we add ignores

Kind of though this one could wait for #1761

[intgr]

Suppose there might be some discrepancy in stubtest for missing modules?

Weird. If it ignores missing stub files, that should be reported as a bug.

I would try it out, but stubtest just fails catastrophically on my setup (reports hundreds of django.db.models.base failed to find stubs errors). I tried re-creating virtualenv and that did not help. Grr!

[flaeppe]

If you get loads of errors, it's probably gis/requirements related, ref: #1602

[UnknownPlatypus]

I also clear mypy cache before every stubtest run, else I have the same issue with loads of errors

[intgr]

Just needs allowlist entry.

[flaeppe]

I'm still getting a stubtest error. But unless I'm missing something I don't find this incorrect?

error: django.contrib.postgres.expressions.ArraySubquery.__init__ is inconsistent, runtime does not have argument "output_field"
Stub: in file /home/runner/work/django-stubs/django-stubs/django-stubs/contrib/postgres/expressions.pyi:244
def (self: django.db.models.expressions.Subquery, queryset: Union[django.db.models.sql.query.Query, django.db.models.query._QuerySet[Any, Any]], output_field: Union[django.db.models.fields.Field[Any, Any], None] =, **extra: Any)
Runtime: in file /opt/hostedtoolcache/Python/3.[12](https://github.com/typeddjango/django-stubs/actions/runs/6712701128/job/18242800501?pr=1765#step:6:13).0/x64/lib/python3.12/site-packages/django/contrib/postgres/expressions.py:9
def (self, queryset, **kwargs)

Found 1 error (checked 859 modules)

It doesn't see that output_field for parent class Subquery is part of **kwargs in subclass ArraySubquery. Not totally sure what Django have tried to achieve by redeclaring ArraySubquery.__init__ though. But I don't see how it would affect any signature?

[flaeppe]

Oh, someone already reacted to that overridden init-signature: django/django#14575 (comment)

So basically it's not possible to declare an output_field= for ArraySubquery. Gonna try and change that

[flaeppe]

Suppose there might be some discrepancy in stubtest for missing modules?

Weird. If it ignores missing stub files, that should be reported as a bug.

I would try it out, but stubtest just fails catastrophically on my setup (reports hundreds of django.db.models.base failed to find stubs errors). I tried re-creating virtualenv and that did not help. Grr!

@intgr for some kind of reference, if it actually was gis related errors you saw too. I figured out a test settings change that helped out getting rid of the errors. Since I didn't have e.g. gdal as a binary available or any of the other binaries django automatically looks for(ref) in my environment I did this change to scripts/django_tests_settings.py:

+import os
# It is used in `mypy.ini` only.
# The following installed apps are required for stubtest to run correctly.
INSTALLED_APPS = [
    "django.contrib.auth",
    "django.contrib.admin",
    "django.contrib.contenttypes",
    "django.contrib.flatpages",
    "django.contrib.redirects",
    "django.contrib.sessions",
    "django.contrib.sites",
]
+gdal_library_path = os.environ.get("GDAL_LIBRARY_PATH")
+if gdal_library_path is not None:
+    GDAL_LIBRARY_PATH = gdal_library_path

+geos_library_path = os.environ.get("GEOS_LIBRARY_PATH")
+if geos_library_path is not None:
+    GEOS_LIBRARY_PATH = geos_library_path

Which makes it possible for me to add the paths to gdal and geos as environment variables and run bash ./scripts/stubtest.sh without errors.

Not completely sure it it's worth adding this diff to master or not? What do you think?

[intgr]

@intgr for some kind of reference, if it actually was gis related errors you saw too.

Ah, no, my issues were solved by removing .mypy_cache between stubtest runs, as suggested by UnknownPlatypus. I did have to install GIS dependencies as well, but they were picked up automatically.

Not against making these tweakable via environment, but it's a bad user experience if users need to tweak these. So I'm ambivalent.

[flaeppe]

I see.

In my case it comes back to not being able to run stubtest as I'm missing the implicit binaries. I suppose I could look into symlinking e.g. gdal and geos_c instead.