Migrate away from abandoned coreapi/coreschema dependency

[ghost]

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 (psf/requests#4417).

[johnthagen]

Migrating issue details from JoelLefkowitz#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 (psf/requests#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: JoelLefkowitz#60 (comment)

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):

encode/django-rest-framework@37f210a

[johnthagen]

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

drf-yasg/src/drf_yasg/generators.py

Line 183 in 789a96c

self._gen = SchemaGenerator(info.title, url, info.get('description', ''), patterns, urlconf)

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: encode/django-rest-framework#7519

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

[johnthagen]

For anyone still tracking this (I've personally ported to drf-spectacular DRF just merged in the DeprecationWarnings to remove coreapi support that drf-yasg relies on

• Added Deprecation Warnings for CoreAPI encode/django-rest-framework#7519

[sevdog]

There are a couple of configs which conflicts with #854

drf-yasg/src/drf_yasg/app_settings.py

Lines 22 to 28 in 6557517

	'DEFAULT_FILTER_INSPECTORS': [
	'drf_yasg.inspectors.CoreAPICompatInspector',
	],
	'DEFAULT_PAGINATOR_INSPECTORS': [
	'drf_yasg.inspectors.DjangoRestResponsePagination',
	'drf_yasg.inspectors.CoreAPICompatInspector',
	],

As of now these are still pinned to the old coreapi ones, this causes swagger generation to crash due to the fact that by default it tries to invoke some DRF methods which requires coreapi.

[onegreyonewhite]

There are a couple of configs which conflicts with #854

drf-yasg/src/drf_yasg/app_settings.py

Lines 22 to 28 in 6557517

	'DEFAULT_FILTER_INSPECTORS': [
	'drf_yasg.inspectors.CoreAPICompatInspector',
	],
	'DEFAULT_PAGINATOR_INSPECTORS': [
	'drf_yasg.inspectors.DjangoRestResponsePagination',
	'drf_yasg.inspectors.CoreAPICompatInspector',
	],

As of now these are still pinned to the old coreapi ones, this causes swagger generation to crash due to the fact that by default it tries to invoke some DRF methods which requires coreapi.

@sevdog Good point. It is high time to switch to receiving parameters not from coreapi. But this is a minor/major change. I can create a class that will take other methods from the paginator and filters, but making it default is better for the maintainer (@JoelLefkowitz )

[darrinmn9]

just an fyi, there is now another deprecation warning related to the coreapi package, that will be removed in 3.13

/python3.11/site-packages/coreapi/codecs/download.py:5:
DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13