django-extensions

django-extensions is a grab-bag of management commands, model fields, admin helpers, and shell utilities that Django developers have found themselves reimplementing on nearly every project, packaged as a single installable Django app. Add it to INSTALLED_APPS and you get commands like shell_plus (an auto-importing enhanced shell), runserver_plus (a Werkzeug-powered dev server with debugger), graph_models (ER-diagram generation from your models), show_urls, and dozens more, alongside reusable model fields like AutoSlugField, UUIDField variants, and timestamp mixins.

The project has been a staple of the Django ecosystem since the mid-2000s, maintained by a large rotating group of contributors, and is commonly one of the first third-party packages added to a new Django project specifically for its development-time productivity commands rather than any single killer feature.

What You Get

• Development-time management commands: shell_plus (auto-imports all models into an enhanced shell), runserver_plus (Werkzeug dev server with an interactive in-browser debugger), notes (scans code for TODO/FIXME/etc.)
• Model introspection and visualization commands: graph_models (Graphviz/mermaid ER diagrams), show_urls, list_model_info, print_settings
• Reusable model fields and mixins: AutoSlugField, ShortUUIDField, timestamp/activator mixins, and JSON field helpers
• Database maintenance commands: reset_db, sqldiff, merge_model_instances, delete_squashed_migrations
• Admin enhancements including a Foreign Key autocomplete widget and improved admin generators
• Utility commands for secrets/passwords (generate_secret_key, generate_password), email (export_emails, set_fake_emails), and scripting (runscript)

Common Use Cases

• Speeding up local Django development with shell_plus and runserver_plus instead of the stock manage.py shell/runserver
• Generating an entity-relationship diagram of a Django project’s models for documentation or onboarding via graph_models
• Adding slug, UUID, or timestamp fields to models without writing custom field classes, and running one-off maintenance commands like reset_db or sqldiff during development

Under The Hood

Architecture: The package is a standard Django “app” (django_extensions/) rather than a standalone framework — it registers via INSTALLED_APPS and contributes management/commands/*.py modules (one file per command, each a BaseCommand subclass), reusable model fields under db/fields/, admin widgets under admin/, and template tags. There’s no central orchestration layer; each command or field is independently self-contained and only shares small utility modules (utils/, compat.py) for cross-cutting concerns like Python/Django version compatibility.

Tech Stack: Pure Python, targeting Django 4.2 through 5.2 and Python 3.9–3.14 per its classifiers. Optional integrations are gated behind extras (Werkzeug for runserver_plus, Graphviz/pygraphviz for graph_models, dateutil, six), so the base install stays lightweight and individual commands fail gracefully with a clear message if their optional dependency is missing.

Code Quality: The tests/ directory mirrors the app’s structure closely, including dedicated fake Django apps (testapp, testapp_with_appconfig, testapp_with_no_models_file) to exercise commands under different project configurations — a sign of real edge-case coverage for a package that has to work across many possible host-project shapes. A tox.ini runs the suite across Python/Django version matrices. With 608 contributors and a long history, code style varies somewhat command-to-command, which is typical for a long-lived “toolbox” package assembled from many individually-contributed utilities rather than a single cohesive design.

API Design: There’s no single API surface to learn beyond Django’s own manage.py <command> convention — each management command follows Django’s standard BaseCommand argument-parsing pattern, and model fields subclass Django’s own field API, so anyone familiar with Django can use most utilities immediately. The trade-off is breadth over depth: the project’s value is in having dozens of small, independently-documented tools rather than one polished, unified interface.