# Django 5 by Example ships one runnable Django project per chapter, not a finished app > The Django 5 by Example repository holds the code for Antonio Mele's Packt book, organised into seventeen chapter directories, each with its own requirements.txt, and every chapter also carries a Docker Compose setup and a management script. It suits a reader working through the book who wants a running project at each step, and it is not a production application you would deploy. **PacktPublishing/Django-5-By-Example** — Django 5 By Example (5th Edition) published by Packt - Repository: https://github.com/PacktPublishing/Django-5-By-Example - Website: https://djangobyexample.com/ - Stars: 558 · Forks: 228 - Language: CSS - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/packtpublishing-django-5-by-example ## Seventeen directories, one per chapter This is the code repository for Django 5 by Example, written by Antonio Melé and published by Packt, and it contains all the supporting project files necessary to work through the book from start to finish. The organising principle is stated in one sentence: the code is organised into directories with the chapter number. Chapter02 contains the source code for chapter 2, and the repository top level runs from Chapter01 to Chapter17 with nothing else in it except the README, the LICENSE and editor configuration files. There is no single application directory and no shared package, which tells you immediately that this is a sequence of stages rather than one evolving codebase. Each chapter folder has a requirements.txt file that includes all packages required to run the code of that chapter, and they are installed with the command `pip install -r requirements.txt` run from inside that chapter directory. That arrangement has a concrete benefit. The dependency set is scoped to the lesson rather than to the final book, so chapter 2 does not drag in Celery and Stripe and Redis because chapters 8 to 11 need them. It also means the working environment changes as you progress, which is a small tax: a virtualenv per chapter, or a deliberate rebuild, depending on how strict you are about the pins. The book itself requires Python 3.12+ and Django 5, and the repository is published under the MIT licence. ## Running a chapter is one command after the install The README gives the development server command in the simplest possible form. ```bash python manage.py runserver ``` That is it for the non-container path. The code is a standard Django project layout, so the usual manage.py entry point applies, and the requirements file per chapter is what stands between you and a working server. The README also says that Docker Compose is explained in Chapter 17, but that all chapters include a Docker Compose configuration and a management script, with a contribution credited to Mark Walker, who is also the technical reviewer of the book. That is a useful detail, because it means you do not have to wait until the final chapter to work in containers. The commands are built and run with a script called do.sh. ```bash ./do.sh build ./do.sh run ``` And the script has a fuller set of subcommands than just those two. The `build []` command builds Docker images, with an optional argument to specify specific images to build. The `exec []` command executes a command in a container. The `compose` command is a minimal wrapper around Docker Compose that ensures the correct configuration files are loaded. The `migrate []` command applies any unapplied Django migrations, and `makemigrations []` creates a new migration with any additional arguments needed. There is a `check` command to validate Django settings, a `shell` command to open a bash terminal in the specified container, which is web_run, and `start []` and `stop []` to start and stop the Django server and its dependent services, with -d for detached mode. That is a well-built wrapper. The `compose` subcommand in particular is the kind of detail that saves time, because a book project with several services usually needs a specific compose file and a specific project name to behave the same way every time. ## Four projects, and what each one teaches The book is organised as four applications, and the topic tags on the repository reflect the technologies they cover: ajax, api, asgi, celery, cms, javascript-programming, nginx, postgres, redis, rest-api-design, restful-web-apis and uwsgi. The Blog Application covers chapters 1 to 3. You build data models, views and URLs, an administration site, canonical URLs and SEO-friendly post URLs, pagination and class-based views, forms for sharing posts by email, and a comment system built on model forms. It adds tags with django-taggit and recommends similar posts based on shared tags, writes custom template tags for latest and most-commented posts and a custom template filter that renders Markdown, and finishes with a sitemap, an RSS feed and a full-text search engine using PostgreSQL. The Social Website covers chapters 4 to 7. Authentication through the Django framework, a custom profile model, the messages framework, a custom authentication backend, OAuth2 with Google through Python Social Auth, django-extensions to run the development server over HTTPS, image thumbnails with easy-thumbnails, many-to-many relationships, a JavaScript bookmarklet, asynchronous HTTP requests with the Fetch API, infinite scroll pagination, a follow system, an activity stream with QuerySet optimisation, Django signals, django-debug-toolbar, and view counting plus image ranking with Redis. The Ecommerce Application covers chapters 8 to 11. A product catalogue, a cart in Django sessions, custom context processors, order management, asynchronous notifications with Celery and RabbitMQ, Flower for monitoring Celery, Stripe payments with a webhook for payment notifications, custom admin views, admin actions generating CSV files, PDF invoices with Weasyprint, a coupon system, discounts integrated with Stripe, a product recommendation engine using Redis, internationalisation with translation files managed through Rosetta, translated URL patterns with a language selector, model translation via django-parler, and localised forms with django-localflavor. The eLearning Platform covers chapters 12 to 17, including a CMS, course models, data fixtures, model inheritance to create polymorphic Content, a custom model field for ordering course contents, authentication views, access restricted by groups and permissions, formsets for managing course contents, and drag-and-drop reordering with JavaScript and Django. ## Why the container setup exists for every chapter The decision to ship a Docker Compose configuration with all seventeen chapters rather than only the last one is unusual for a book repository, and it is worth explaining why it matters. The later projects need services that a Python virtualenv cannot provide. Redis for view counting and image ranking, RabbitMQ as the Celery broker, PostgreSQL for the full-text search, and a web server with uwsgi or nginx for the deployment chapters. Without containers, a reader working through chapter 8 would have to install and configure Redis and RabbitMQ locally, then discover the configuration differences between their machine and the book's. With containers, the services come up with the chapter. The do.sh script exists to make that repeatable, and the subcommand list shows it covering both directions: starting and stopping the server and dependent services, running migrations inside the container, opening a shell in web_run for interactive work, and validating settings. The `migrate` and `makemigrations` subcommands are a small but telling detail. In a container setup the command runs against the containerised settings and the containerised database, so an argument can be passed through to the underlying manage.py call. That is the difference between a compose file that works and one that half-works. The trade is that the container path adds a Docker dependency to a learning project, and on a machine without Docker the plain `python manage.py runserver` path with a local Postgres and Redis is the only option. ## What you get, and what you do not It is worth being explicit about the boundaries of this repository, because book code repositories are often mistaken for finished applications. What you get is code that runs. Each chapter's application is complete enough to start, migrate and browse, which is more than many book code samples offer, and the per-chapter requirements files mean you can jump to any chapter rather than working forward from the first. What you do not get is a single deployable product. There is no settings module for production, no environment configuration, no CI, and no unified dependency file across chapters. The chapter code exists to demonstrate one topic at a time, and in several places the code is deliberately simple in a way a production system would not be, such as the debug toolbar in the social project. There is also no versioning to pin to. The repository has no GitHub releases, so there is no tagged version corresponding to the fifth edition of the book. The last push was on 2026-05-23, and the repository is not archived. The MIT licence is the permissive one, with the LICENSE file at the repository root, so the code is free to reuse in your own project without copyleft obligations. For a book repository that matters more than it might seem, because many readers end up lifting a chapter's implementation into a real project. ## Who the code is for, and how to use it The intended reader is a developer who has bought or borrowed the book and wants the code to match the text. The README describes the book as guiding you through the entire process of developing professional web applications with Django, covering the most relevant aspects of the framework while teaching how to integrate other popular technologies into Django projects, walking through four real-world applications with a step-by-step approach. The practical usage pattern has three options, and they suit different readers. The first is to follow along, creating each chapter's project yourself and using the repository as the reference for what should exist at the end of the chapter. That is the slowest path and the one the book is designed for, since the code changes between chapters and the differences are the lesson. The second is to jump. Because every chapter is self-contained with its own requirements, a reader who wants only the Celery and Stripe chapters can install chapter 10's requirements and start from there. The third is to lift. A developer who wants to add a shopping cart to an existing project can read chapters 8 to 11 and copy the model and view patterns, which is legitimate under the MIT licence. What the repository cannot do is replace the book. The prose explains why each design choice was made, and the code alone loses that. For someone who already knows Django well and wants a pattern reference, the chapters are browsable. For someone learning, the pairing matters. ## Where this repository is the wrong choice Three situations make it a poor fit. The first is a current project. The requirements are Python 3.12+ and Django 5, and the code follows Django 5 conventions. If you are on Django 6 or planning to move to it, the code becomes a source of outdated patterns you have to audit rather than copy, especially in areas where Django has been changing, such as the class-based view internals and the settings layout. The second is expecting a production template. There is no hardened settings module, no environment separation, no secrets handling, no logging configuration and no test suite in the repository listing. Using a chapter's code as the base of a production service means writing all of that yourself, and the book code will not be structured to make it easy. The third is local-first development without Docker. The later chapters assume services, and the container configuration is the supported path. Installing Redis, RabbitMQ and PostgreSQL by hand on each machine is workable but puts the setup burden back on you, which is exactly what the do.sh script was written to avoid. The alternative for someone who wants a working Django application to read rather than a book to follow is to take a single well-maintained open source Django project and read its structure. That gives you production patterns including the ones the book skips, at the cost of not learning the progression. The book repository is the better choice when the goal is to understand how a feature is built, since it shows the intermediate state that a finished project hides. ## Conclusion Django 5 by Example fits a developer who has decided to work through the book and wants each chapter's code to run rather than be reconstructed, since the per-chapter requirements and the Docker setup remove most of the setup friction. It does not fit a team looking for an application to build on, because the code is organised as teaching stages rather than as a coherent product, and it does not fit a Django 6 or Python 3.13 project. Read the requirements file for the chapter you are on rather than the whole tree, and note that the last push to the repository was on 2026-05-23 with no GitHub releases published. ## FAQ ### What is the Django 5 by Example repository? It is the code repository for Django 5 by Example, written by Antonio Melé and published by Packt, containing the supporting project files for the book. The code is organised into directories named by chapter number, from Chapter01 to Chapter17. ### How do I run the code for a chapter? Install that chapter's dependencies with `pip install -r requirements.txt` from inside the chapter directory, then start the development server with `python manage.py runserver`. Every chapter also ships a Docker Compose configuration and a do.sh management script with build, run, migrate, makemigrations, check, shell, start and stop subcommands. ### Which projects does Django 5 by Example cover? Four: a blog application in chapters 1 to 3, a social website for bookmarking images in chapters 4 to 7, an ecommerce application in chapters 8 to 11, and an eLearning platform with a CMS in chapters 12 to 17. Between them they cover PostgreSQL full-text search, Redis, Celery with RabbitMQ, Stripe, Weasyprint, OAuth2 with Google, and internationalisation. ### What versions of Python and Django does the book need? The book requires Python 3.12+ and Django 5. Each chapter directory carries its own requirements.txt listing the packages needed to run that chapter's code. ### Can I use the Django 5 by Example code in my own project? The repository is published under the MIT licence with the LICENSE file at the root, so the code can be reused without copyleft obligations. The code is organised as teaching stages rather than as a single application, so there is no production settings module, CI configuration or unified dependency file to inherit. ## Sources - [Issues](https://github.com/PacktPublishing/Django-5-By-Example/issues) - [License: MIT](https://github.com/PacktPublishing/Django-5-By-Example/blob/main/LICENSE) - [PacktPublishing/Django-5-By-Example on GitHub](https://github.com/PacktPublishing/Django-5-By-Example) - [Project website](https://djangobyexample.com/) - [README](https://github.com/PacktPublishing/Django-5-By-Example/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/packtpublishing-django-5-by-example