Django Template

An opinionated Django start project template.

How to Use

Using Cruft (Recommended)

Cruft is compatible with Cookiecutter and is the recommended method because it allows you to update the project with the latest template changes using cruft update.

pip install cruft
cruft create https://github.com/lucasrcezimbra/django-template

Using Cookiecutter

pip install -U cookiecutter
cookiecutter https://github.com/lucasrcezimbra/django-template

Features

• dj-database-url to cast database URL to Django setting
• django-extensions for custom extensions for Django
• docker with compose
• GitHub Actions for CI
• Gunicorn as WSGI HTTP Server
• PostgreSQL database
• pre-commit with black, ruff, yamlfmt, actionlint, and pre-commit-hooks
• pytest-django, pytest-mock, and models_bakery for tests
• python-decouple to organize settings and decouple from code

Optionals:

• Django HTMX
• Django Ninja and Django Ninja CRUD to build APIs
• djLint and djade
• Dockerfile, Heroku or Render to deploy
• Sentry for error tracking
• WhiteNoise to serve static files

Tree

*optionals

api
├── api
│   ├── asgi.py
│   ├── core
│   │   ├── admin.py
│   │   ├── api.py*
│   │   ├── apps.py
│   │   ├── __init__.py
│   │   ├── managers.py
│   │   ├── migrations
│   │   │   └── __init__.py
│   │   ├── models.py
│   │   ├── templates*
│   │   │   └── index.html
│   │   ├── tests
│   │   │   ├── test_api.py*
│   │   │   ├── test_crud.py*
│   │   │   └── test_view_index.py*
│   │   └── views.py*
│   ├── __init__.py
│   ├── settings.py
│   ├── static*
│   │   └── htmx.min.js.gz
│   ├── urls.py
│   ├── users
│   │   ├── admin.py
│   │   ├── apps.py
│   │   ├── __init__.py
│   │   ├── managers.py
│   │   ├── migrations
│   │   │   ├── 0001_initial.py
│   │   │   └── __init__.py
│   │   ├── models.py
│   │   ├── tests
│   │   │   └── test_users.py
│   │   └── views.py*
│   └── wsgi.py
├── contrib
│   ├── env-sample
│   └── secret_gen.py
├── docker-compose.yml*
├── Dockerfile*
├── .dockerignore*
├── .env
├── .github
│   ├── dependabot.yml
│   └── workflows
│       └── python-app.yml
├── .gitignore
├── manage.py
├── .pre-commit-config.yaml
├── Procfile*
├── pyproject.toml
├── README.md
└── render.yaml*

Rationales

Custom user model

If you’re starting a new project, it’s highly recommended to set up a custom user model, even if the default User model is sufficient for you. This model behaves identically to the default user model, but you’ll be able to customize it in the future if the need arises

from https://docs.djangoproject.com/en/5.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project

Custom user model in a isolated app

It's difficult to migrate the custom user model to a new app after the project is created.

You may need to move your custom model to a new app to use app like django-tenants and django-tenant-users.

To avoid these migration issues, the custom user model is created in an isolated users app.

Contribute

Contributions are welcome, feel free to suggest improvements.