Drf-yasg: Migrate away from abandoned coreapi/coreschema dependency

[sad-boy-uoa]

Hi there,

I've just noticed that this library depends on the coreapi which has been deprecated. What is the strategy going forward to work around this?

As per the coreapi github page:

DEPRECATION NOTICE: As of djangorestframework 3.9, the plan is to phase out CoreAPI in favor of OpenAPI as the default schema representation. New projects should consider using OpenAPI rather than CoreAPI. See the DRF 3.9 release announcment for more details.

[axnsan12]

Well, to be honest, if the OpenAPI implementation in DRF is up to snuff, the plan would be to deprecate this library altogether 🙂 Time will tell.

Otherwise, we'll have to review which parts of coreapi are used here and how we can replace them.

[onegreyonewhite]

@axnsan12 You cant drop coreapi until in rest_framework.schemas.corepai.SchemaGenerator is used and DRF<3.11. But you can stop using coreapi imports. Check #588 for it.

[johnthagen]

Another benefit of removing the dependency on coreapi is that coreapi depends on requests, which depends on chardet. chardet is LGPL licensed which presents problems for developers wanting to package their application as a binary using PyInstaller or PyOxidizer (https://github.com/psf/requests/issues/4417).

[johnthagen]

Migrating issue details from https://github.com/JoelLefkowitz/drf-yasg/issues/60. Given that this is a long-term maintenance risk for the project, I am going to pin this issue for more visibility.

From the core-api repo:

DEPRECATION NOTICE: As of djangorestframework 3.9, the plan is to phase out CoreAPI in favor of OpenAPI as the default schema representation. New projects should consider using OpenAPI rather than CoreAPI. See the DRF 3.9 release announcment for more details.

DRF will soon be raising deprecation warnings for CoreAPI schemas and they will be removed in DRF 3.14. I haven't looked closely enough at drf-yasg2 to know if this will affect this package, or if we only rely on coreapi directly rather than through DRF itself.

The coreapi Python package is frozen and has not seen a release in 3 years. It was last tested on Python 3.6. This is a liability for the long term health of this project. This upstream issue would have broken drf-yasg[2] on Python 3.10, but a maintainer took over one of coreapi's frozen dependencies, itypes and fixed the issue.

Another benefit of removing the dependency on coreapi is that coreapi depends on requests, which depends on chardet. chardet is LGPL licensed which presents problems for developers wanting to package their application as a binary using PyInstaller or PyOxidizer (https://github.com/psf/requests/issues/4417).

Seems like we should try to identify and migrate over the parts of coreapi that are needed for drf-yasg2.

coreapi also brings in coreschema which is used by drf-yasg2. coreschema has also not been maintained for 3 years.

[axnsan12]

We depend on the coreapi for filters (in particular: django-filter) and paginators compat https://github.com/axnsan12/drf-yasg/blob/master/src/drf_yasg/inspectors/query.py

I imagine this could be replaced to use some new interface which is now used by DRF for its openapi schema

[johnthagen]

In case it helps, I also made a listing of everywhere coreapi and coreschema are used in the drf-yasg2 fork for reference.

Here is the comment: https://github.com/JoelLefkowitz/drf-yasg/issues/60#issuecomment-711166378

It seems that potentially they could be tackled independently?

[axnsan12]

The coreapi.compat ones should be easy since it was just used as a lazy python 2 compatibility shim.

urlparse -> from urllib.parse
force_bytes -> from django.utils

[axnsan12]

It seems that get_schema_operation_parameters and get_paginated_response_schema are the replacements for get_schema_fields:

https://github.com/encode/django-rest-framework/blob/04e0c2b9ab6616a28148ce32e2d19858ccfe6c69/rest_framework/pagination.py#L228
https://github.com/encode/django-rest-framework/blob/04e0c2b9ab6616a28148ce32e2d19858ccfe6c69/rest_framework/filters.py#L162

[axnsan12]

Those APIs were added in DRF 3.10 so we are already clear from a compatibility pov to use them unconditionally (and drop coreapi/coreschema completely):

https://github.com/encode/django-rest-framework/commit/37f210a455cc92cb3f61a23e194a1d0de58d149b

[johnthagen]

When starting some work on this in #664, I discovered there is another hidden dependency on coreapi here:

https://github.com/axnsan12/drf-yasg/blob/789a96cd90f8993979cceffb8d7a3a14408c47eb/src/drf_yasg/generators.py#L183

DRF will throw an exception from rest_framework.schemas.coreapi.SchemaGenerator if coreapi is not installed:

https://github.com/encode/django-rest-framework/blob/04e0c2b9ab6616a28148ce32e2d19858ccfe6c69/rest_framework/schemas/coreapi.py#L120

[johnthagen]

Okay, I've confirmed that the remaining coreapi usage will start throwing RemovedInDRF315Warnings starting in DRF 3.13 and will be removed in DRF 3.15: https://github.com/encode/django-rest-framework/pull/7519

So we have a relatively short timeline to avoid warnings being generated in drf-yasg projects and then later actual breakages.