First of all, thank you very much for your kind words. It has been a lot of work that started simply out of desperation for a usable solution. Now I'm just enjoying that fact that it's used quite successfully in the wild. You could say I already was a pro user before, but writing this tool made me learn details about Django and DRF that I neither knew existed nor that I really ever wanted to know honestly.

@carltongibson regarding a recommendation. Very much appreciated and I also think it is a good time. drf-spectacular has been very stable and I consider it mature at this point in time. We solved hundreds of issues and most new legitimate bugs are super esoteric edge cases that rarely anyone ever hits. The steady decline in bug reporting in conjuction with the amount of users tells me that we reached a nice plateau of stability. That also means the API is not expected to change in any significant way anymore (and has not for quite some time now).

regarding deprecating parts of the DRF code: It is not a issue for us. Do as you see fit. We have very little hard dependencies left. As you said, we depend on the mechanics that were provided to us. I also want to stress that those mechanics have way more hidden complexity behind them than people realize. It's a good and stable API and as long as that is not gonna change in a significant way, we are good! Code wise, we probably have zero lines dependencies in AutoSchema, a few lines in EndpointEnumerator, and some lines in SchemaGenerator. Pulling those few functions into our codebase is trivial, we would just need the heads-up on what and when.

Side-mark: what about core-api and "The Browsable API"? Is this still adding value to anyone? It was nice to have when nothing else was available, but nowadays using OpenAPI/SwaggerUI/drf-spectacular makes those old approaches seem quite antiquated with very little added benefit. Personally, I do love SwaggerUI! It's a fantastic well-maintained tool with a strong community. DRF is never gonna match this, so why keep reinventing a subpar wheel. I absolutely agree with you @carltongibson that it's better for DRF to focus on the core and stand on the shoulders of giants when it comes to those auxiliary topics.

Regarding the discussion where the schema code should live. Well, it's the old framework or library question. Here are some thought on the nitty gritty:

• DESIGN & RESPONSIBLITY & KNOWLEDGE: From a design perspective, the schema code should probably live in the library (e.g. django-filter), but in reality it is not that clear cut. Yes, maintainers should know how their code is supposed to behave, but that does not mean they know how to properly bake that into a OpenAPI specification.
• TOOLING: Some libraries require significantly more logic than DRF offers at the moment. drf-spectacular does offer those amenities, but it would create a dependency. For example, deriving model field specs is complicated and package maintainers will not write hundreds of complicated lines for that alone. I suppose maintainers will not even bother without those toolings available to them. Also writing those schema methods correctly is not an easy feat. Writing the auth definition for the bearer auth took me like 5 attempts (with the help of a handful of people) to finally get right. It's harder than it looks.
• COMMUNITY SUPPORT: Also some of the heavily used libraries are not that well maintained, un-maintained, or the maintainer is very defensive when it comes to changing things (looking at you @carltongibson 😄). Relying on their cooperation alone would make this whole thing dead on arrival. drf-spectacular would have never gained traction, if I have had to convince 20 different maintainers on why we need some particular change time and again. Realistically, this is just never going to happen in a satisfactory way. The drf-spectacular extension system was designed to make this a flexible two way street for both package maintainers and users with special needs. This really made the difference imho.

@n2ygk regarding Django OAuth Toolkit (don't know what DJA stands for):

https://github.com/tfranzel/drf-spectacular/blob/master/drf_spectacular/contrib/django_oauth_toolkit.py

We do ship with that support out-of-the-box and we do make use of what we can with BaseAuthentication and BasePermission.

Essentially, we did the same thing as you, but made it so that it's more pluggable and easier to work with. Please let me know if there is some gap for you there. I realized some time ago that this whole thing works so ridiculously automagically that people sometimes stumble over that simplicity on first contact.

This also is a good example for the above TOOLING and KNOWLEDGE points. Afaik this extension works quite well for us. Let me know if there is anything missing for you. Sry for the effort you put into that PR, but maybe we can cherry-pick some aspects if we missed something on our side.

Please let me know what you think @carltongibson @n2ygk! It's a big interconnected set of issue and writing down all my learnings from the past 2 years is quite hard, but I'll happily expand where needed.