Drop coreapi support for DRF 3.17

[TGoddessana]

Description

refs #8453

As discussed in #8453, we are deprecating the coreapi for drf 3.17.

I read the discussion in detail, and I'm wondering if it was decided to “leave all schema generation logic in the library that generates the schema (drf-spectacular), and drf will not be involved in schema generation” (drf-spectacular will be part of drf?) The comments in the linked discussion say that...

Yes. The idea would be to leave (just) the extension points in place, as they are.

[TGoddessana]

Question while working with PR.

The documentation says: “Support for generating default schemas will be moved to a separate package and then removed”. For this PR, should we remove coreapi and everything related to it, or all code related to the whole rest_framework/schemas/ package?

If you need to remove everything related to schemas from the Rest Framework, you can remove most of the code, tests, etc. in /schemas. What do you team think about this?

[TGoddessana]

@auvipy I'm sorry if the tags are annoying. But this is the only place we can make design decisions about PR, and I'd love to hear your thoughts on what I should do..

[auvipy]

yes please fix the merge conflicts as we have to remove it

[TGoddessana]

I guess this is where we need to make a decision on where we stop supporting it... For example, should we remove all schema-related references in rest_framework.settings since schema generation will stop?

The documentation certainly mentions that we will be removing API documentation, but I'm confused if removing all code like schemas.utils or renderers.CoreJSONRenderer is included in this scope.

[TGoddessana]

For example, the APIView class defaults to the DefaultSchema() class that was included in the schema package.

If we were to remove schema generation, would it be right to remove these codes as well?

[browniebroke]

That's a big one! I didn't expect to see some much code deleted, but I can see there was a lot of tests...

If we were to remove schema generation, would it be right to remove these codes as well?

Would be interesting to see what drf-spectacular or drf-yasg are using to hook into DRF, and make sure we don't break their integration point. Might be a good idea to coordinate this with them.

[TGoddessana]

Alright, I think it's best to restart the PR, so I've reverted the commit. Both packages directly depend on this part of rest_framework. Let's see this..

(Some parts of this content were generated using AI. :) I think it's a really useful tool for situations like this. But basically, I found and verified all the code references myself.)

drf-spectacular

Essential Components to Maintain

Component	Location	Type	Purpose	drf-spectacular Usage
ViewInspector	rest_framework.schemas.inspectors	Base Class	Core schema inspection interface	Inherited by AutoSchema class
BaseSchemaGenerator	rest_framework.schemas.generators	Base Class	Schema generation interface	Used by drf-spectacular generators
BaseEndpointEnumerator	rest_framework.schemas.generators	Base Class	API endpoint discovery logic	Extended by EndpointEnumerator
get_pk_description	rest_framework.schemas.utils	Utility Function	Primary key field description	Direct import and usage

Components Safe to Remove

Component	Location	Type	Reason for Removal
AutoSchema (DRF's implementation)	rest_framework.schemas	Class	Replaced by drf-spectacular's AutoSchema
CoreAPI schema generators	rest_framework.schemas.coreapi	Module	Legacy schema format
OpenAPI 2.0 generators	rest_framework.schemas.openapi	Module	Superseded by drf-spectacular
Schema view implementations	rest_framework.schemas.views	Module	Custom implementations available

Critical Interfaces to Preserve

Interface	Method/Attribute	Required for Compatibility
ViewInspector	get_operation()	Method signature and base behavior
ViewInspector	get_description()	Method signature
ViewInspector	get_summary()	Method signature
BaseEndpointEnumerator	get_api_endpoints()	Method signature and return format
BaseEndpointEnumerator	get_path_from_regex()	Method signature
BaseSchemaGenerator	Base interface	Class structure and constructor

drf-yasg

Essential Components to Maintain

Component	Location	Type	Purpose	drf-yasg Usage
EndpointEnumerator	rest_framework.schemas.generators	Base Class	API endpoint discovery logic	Extended by custom EndpointEnumerator
SchemaGenerator	rest_framework.schemas.openapi	Base Class	OpenAPI schema generation	Used as base for drf-yasg generator
get_pk_description	rest_framework.schemas.utils	Utility Function	Primary key field description	Direct import and usage
get_pk_name	rest_framework.schemas.generators	Utility Function	Primary key field name extraction	Direct import and usage
endpoint_ordering	rest_framework.schemas.generators	Utility Function	Endpoint sorting logic	Direct import and usage
AutoSchema	rest_framework.schemas	Class	Schema inspection interface	Used internally by SwaggerAutoSchema

Components Safe to Remove

Component	Location	Type	Reason for Removal
DRF's default OpenAPI implementation	rest_framework.schemas.openapi	Implementation	Replaced by drf-yasg's implementation
CoreAPI schema generators	rest_framework.schemas.coreapi	Module	Legacy schema format
Default schema view implementations	rest_framework.schemas.views	Module	Custom implementations available

Critical Interfaces to Preserve

Interface	Method/Attribute	Required for Compatibility
EndpointEnumerator	get_path_from_regex()	Method signature and regex processing
EndpointEnumerator	should_include_endpoint()	Method signature for endpoint filtering
SchemaGenerator	Base class structure	Constructor and inheritance compatibility
AutoSchema	view attribute	Used by SwaggerAutoSchema._sch.view
Utility functions	Import paths	All utility function locations must remain stable

Key Differences from drf-spectacular

Aspect	drf-yasg	drf-spectacular
Base Schema Class	Uses AutoSchema internally	Inherits from ViewInspector
Generator Approach	Extends SchemaGenerator	Uses BaseSchemaGenerator
Endpoint Discovery	Heavily customizes EndpointEnumerator	Extends BaseEndpointEnumerator
Utility Dependencies	More extensive use of DRF utilities	Minimal utility usage

[TGoddessana]

In my view, there are two possible approaches:

1. Remove all schema-related code and settings from DRF, requiring both packages to redefine the relevant dependency code within the schemas package. This would fully eliminate the schema generation logic, which I believe results in a cleaner overall design.

2. Retain the dependent code as summarized above. While this would leave some legacy code in place, it would preserve compatibility.

From a maintenance perspective, I tend to favor Option 1 (removing all schema-related code). The deprecation of coreapi has been clearly noted in both the codebase and documentation for some time, and it seems more sustainable for DRF not to maintain direct dependencies on third-party packages(similar to how Django continues to evolve without holding back updates purely for compatibility with DRF.).

[TGoddessana]

drf-spectacular directly uses these items from the existing DRF's settings.py.

DEFAULT_SCHEMA_CLASS COERCE_DECIMAL_TO_STRING UPLOADED_FILES_USE_URL URL_FORMAT_OVERRIDE FORMAT_SUFFIX_KWARG 

As long as DRF does not participate in schema creation, could removing the DEFAULT_SCHEMA_CLASS api from the above items be a good starting point?

[browniebroke]

Sorry about the lack of feedback here, I'm not too sure how to get this one across the line without breaking other documentation packages like drf-spectacular, and will need some time to understand that.

We are aiming to move the project to @django-commons on Friday and as part of the move, we're planning to do a release. With the list of unreleased changes on main, we will have to bump the minor digit to 3.17, but realistically this PR won't make the cut.

Would you be interested in sending a pull request to update the deprecation warning from 3.17 to 3.18? feel free to say no if you won't have time...

Thanks!

[browniebroke]

As this is a bit time sensitive, I've done it in #9810

Let's go back to this once it's merged. Thanks for your patience.

[auvipy]

lets wait until 3.18

[TGoddessana]

I apologize for the delayed response. I've been personally busy and going through a difficult time.

Thank you for working on the package. As you suggested, I think it would be best to consider up to version 3.18.

As mentioned, I think the cleanest approach is to remove all schema-related code (packages, tests). It won't be easy to maintain the code without breaking the integration points for both packages (drf-spectacular, drf-yasg).