Nice one! Consider a follow up article with 1. Alpine Linux as the base image to significantly reduce the size and 2. Build the requirements in one layer, and then transfer the codebase to a new layer to further reduce size.

First of all, I would rather use docker-compose, not a single docker build, since your app can grow. Speaking of growing, I would separate dev & prod docker-compose.

> When we develop more than one python project, we need to configure our development environment with the dependencies of all the projects.

use pyenv and simple virtualenvs.

I think you are trying to substitute a virtualenvs with a docker. Why trying to kill a sparrow with a cannon?

while i agree this is overly complex given the simplicity of virtualenvs, there is something “pythonic” about encapsulating the environment in a container.

I would suggest using alpine containers with python for a ~40mB container, versus the ~900MB container created here to run a server.

For me, python containers are only used when I want to bundle things into services on swarm, and I use venvs for local development.

How is this easier than sharing a requirements.txt and a requirements-dev.txt on git and having a venv per python project?

At least it circumvents https://xkcd.com/1987/ to some extent. It sometimes feels like half the [python] questions on Stack Overflow are from persons confused about how and where packages get installed and what Python they are actually running.

It doesn’t circumvent anything, it just adds another place that people can potentially be confused. Now you have your site packages in a Linux file system in a container you need to fiddle with, and so you install your packages there in a virtual env? Do you use cobra? Etc.

Not saying docker isn’t a good solution sometimes, but if you just want to manage local python dev environments venv will get you through it with far less complexity and far less confusion.