django-filters emits warnings during schema generation

[jayvdb]

Describe the bug
Very low priority, but worth starting to investigate..

/usr/lib/python3.8/site-packages/django_filters/rest_framework/backends.py:147: UserWarning: <class 'foo.views.FooReportView'> is not compatible with schema generation
  warnings.warn(

If nothing else, the occurrence of these warnings is distracting, and not as informative as the warnings from drf-spectacular. Very likely they existing because of the way DRF core swagger support is/was built, and it is a useful warning for the benefit of people using the DRF core schema generation.

To Reproduce
I should be able to get a snippet if it is necessary, but it would probably be easier to replicate with a new sample meeting the criteria explained fairly easily based on the django-filters code which is getting triggered.

Expected behavior
Some of the time, but rarely it seems, drf-spectacular is doing a reasonable job despite django-filter saying there is a problem. I would need to study the generated schema more closely to understand this.

Other times, the warning from django-filters is appropriate, and drf-spectacular also emits a warning about the same thing.

Long term, the warning should be avoided because it is either redundant or incorrect. It could be avoided either by drf-spectacular pre-empting the same conditions and not invoking that code, or by filtering the warning in advance or reformatting it if it was an unexpected warning and include it in the warnings that drf-spectacular counts.

[tfranzel]

i had a quick look and it seems django-filters does not like being accessed without an request. maybe this is solved by always providing a mock request. i believe it happens on getting the queryset. we have "hacky" fallbacks for going around the queryset, which we do use on missing querysets. though imho the queryset it is still the most robust way extract info.

i agree this is not pretty but we might not be able to prevent it without doing some horrible hacks.

i'm not in favor or magically altering stdout/stderr behaviour to make those dissapear. at least not by default. that might lead to hard to debug problems.

[jayvdb]

this is solved by always providing a mock request.

I have a WIP for this, but not polished enough to PR. Can have it ready by next week.

i'm not in favor or magically altering stdout/stderr behaviour to make those dissapear.

I am talking about stdlib filterwarnings followed by resetwarnings, or catch_warnings, which can be very precise in filtering out only the one warning, but only if we determine that the logic behind that warning is due to assumptions about drf-yasg/drf-core that do not apply to drf-spectacular.

[tfranzel]

there have been several improvements in that regard (global mocked requests). also there is improved django-filter support available now. does this issue persist?

[tfranzel]

there have been further improvements to django-filter and i strongly suspect that this issue is gone now. closing due to inactivity. we can reopen if the issue still persists.