Why do not make drf-yasg an official OpenAPI schema generation library?

[mkurnikov]

https://github.com/axnsan12/drf-yasg
Internally, we're using it since the inception, it works great.

Just trying to understand. djangorestframework tries to add support for OpenAPI schema generation for some time now
#6119
#6532

Wouldn't it be more efficient to make drf-yasg an official library and add necessary abstraction for it to reuse parts of DRF (IIRC, @axnsan12 had to copy and patch some DRF code to make it work).

[axnsan12]

Hello!

Personally, I don't think drf-yasg is good enough to be integrated in DRF, because there is no OpenAPI 3 support. This was acceptable back in 2017, when the OpenAPI 3 spec was just being finalized, but now it's a major downside. OpenAPI 3 brings a number features that address some pain points in describing DRF endpoints, so IMO any generator that is developed/integrated into DRF must support that.

As for why drf-yasg is stuck on OpenAPI 2, that's because there are major structural differences between the two specs and a significant amount of logic would have to be adapted. I haven't found the time for that, sadly.

[carltongibson]

#6119 was a preliminary. Time was the limiting factor there, so it was paused.

#6532 is no-doubt incomplete but ≈working. It'll be in place for the 3.10 release.

IF you're using OpenAPI then input there, either in issues, or PRs on the branch even, would be much appreciated.

So, I need to tidy up the new code, deprecate the CoreAPI based stuff and document the integration with APIStar (which will be the option for "Interactive Docs" rather than those being included in DRF itself) (You'll be free to use whatever you want obviously.)

On the generateschema side, what would be great is input on what — from the important bits — we're not generating right yet. Install the branch, give it a run and report back or contribute.

For example, operation ids are not yet in place. They're not strictly required, but practically they probably are. So feedback along those lines confirming that, or a PR adding them: super!

For example, we're generating request and response bodies from serialisers but moving those to components would make the generated schemas smaller, and more readable. A pr adding that: super!

For example, there are a few TODOs in the code. Comments on those, or PRs fixing them: super!

I'll leave this open for a bit so perhaps people read it. 🙂