Django Batteries versus packages

A clarifying post on terminology today. Django is described as having "batteries included", this generally means tha common tasks are easy to do and have been thought about, normally with some code of some form already written. The package ecosystem provides most of these batteries, while Django provides the core batteries we need to build web applications.

The clarifying point here is that when we talk about adding batteries into Django, the first thing that normally comes to mind is the desire to add more code in the form of packages into core. This desire and assumption is dangerous and not within the grain of Django (thanks Carlton!).

Batteries to me are features or specifications. The closest thing you get to functioning code is an API specification of how you expect the battery to work when interacting with the rest of the project. More often it would take the form of a written specification.

Packages are the most common implementation of a Battery whether in core or outside as a separate package. But a Battery could easily be written in another language (eg ASGI/WSGI servers) or could be a remote API with minimal python included.

Why make this distinction? It's fairly simple in my mind, before any talk of what of how packages get promoted (in whatever form) into core or elevated in the documentation, we first need to establish the batteries that we want included. This obviously changes over time, but in order to maintain the stability of Django I think the distinction is crucial to conversation around packages and features for Django.