Can 'coreapi' dependency be dropped?

[intgr]

What's wrong

Hi! In my project, djangorestframework-stubs's dependency on coreapi pulls in several unneeded dependencies, which could otherwise be removed.

djangorestframework-stubs 1.4.0 PEP-484 stubs for django-rest-framework
├── coreapi >=2.0.0
│   ├── coreschema * 
│   │   └── jinja2 * 
│   │       └── markupsafe >=0.23 
│   ├── itypes * 
│   ├── requests * 
│   │   ├── certifi >=2017.4.17 
│   │   ├── chardet >=3.0.2,<5 
│   │   ├── idna >=2.5,<3 
│   │   └── urllib3 >=1.21.1,<1.27 
│   └── uritemplate * 
│   ...

I don't entirely understand the relationship bertween DRF and coreapi, since I haven't used that functionality. But I notice that DRF upstream has been deprecating the dependency, and the latest 3.12 version no longer requires it.

https://www.django-rest-framework.org/community/3.10-announcement/

This release begins the deprecation process for the CoreAPI based schema generation, and introduces OpenAPI schema generation in its place.

---

I can put in some development work myself, but I don't know where to start yet. So first I wanted to see if the maintainers already have an idea about what needs to be done?

[sobolevn]

The thing here is that we don't have any versioning policy yet. In django-stubs we at least have this: https://github.com/typeddjango/django-stubs/#version-compatibility

I think, that coreapi can be dropped after drf drops it.

[johnthagen]

I wanted to echo this as a pragmatic decision to help end users. coreapi hasn't seen a release since 2017 and there are real consequences to including it when trying to lock dependencies and audit everything being pulled in.

Could coreapi be made an optional dependency of djangorestframework-stubs as a start so users could opt in if they need?

If it were an extra_requires it could be opted-in like:

pip install djangorestframework-stubs[coreapi]

Since DRF doesn't install coreapi by default, perhaps the stubs should follow suit?

My personal opinion is that given the multitude of far superior options (drf-spectacular, drf-yasg, or even the built in DRF schemas) I honestly doubt that someone using modern enough Python features to opt into extra type checking would still be using coreapi.