Question while working with PR.

Thedocumentation 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 wholerest_framework/schemas/ package?

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

@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..

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

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 likeschemas.utils orrenderers.CoreJSONRenderer is included in this scope.

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?

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.

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

Components Safe to Remove

Critical Interfaces to Preserve

drf-yasg

Essential Components to Maintain

Components Safe to Remove

Critical Interfaces to Preserve

Key Differences from drf-spectacular

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 theschemas 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 ofcoreapi 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.).

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

DEFAULT_SCHEMA_CLASSCOERCE_DECIMAL_TO_STRINGUPLOADED_FILES_USE_URLURL_FORMAT_OVERRIDEFORMAT_SUFFIX_KWARG

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

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!

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.

lets wait until 3.18

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