Developing inside a docker image seems like needless complexity to me, especially when virtualenv takes care of the python environment isolation already without another layer of indirection. Virtualenvs are just file copies and PATH vars with some tooling.

Maybe if what you are building runs comfortably in one app, on one server, with no important discrepancies between your dev system and production.

The environment I work with has docker containers for

    Web App Server
    Background Task Worker Server
    Database
    Redis Node
    Cassandra Node

Getting all of these to work nicely together on linuxes/macOS/Windows in a repeatable fashion across multiple developers is a major headache. Being able to spin the whole cluster up with `docker-compose up -d` turns the whole mess into merely a minor headache.

Most of the time, I only need to work on functionality that depends on DB and WEB nodes, but if I ever need to debug some issue with the worker tasks, it's much easier to have a whole working system available.

Agreed. If you're on Windows/OSX, it also adds a VM between your host and your code and file sharing has terrible performance.

File sharing performance has gotten much better on OS X, at least: https://blog.docker.com/2017/05/user-guided-caching-in-docke...

It's still not /great/. I have had to switch from my mac to a new Win10 laptop for development because the app server in my docker container would take around 2 mins to detect a change and reboot the app server, which then would take a few minutes to reboot. Now it's much closer to realtime. I do hope that docker get's it sorted out soon, as the tooling on windows isn't as good as what I am used to on osx.

And by tooling, I mean command line. I am using Cmder with Linux subsystem for Windows, and it STILL isn't half as good as even the terminal built into osx, let alone iterm.

Docker might replace the need for the virtual environment, but doesn't manage the components of a Python project (building, testing, installing and updating dependencies, etc).

Plus, a virtualenv is a much simpler tool, it's essentially just a way to tell the Python interpreter from which directories to load modules, so it's less likely to give you problems.

It doesn't. Imagine you just want to run some utility written in Python (let's use youtube-dl since it is been on front page lately), why do I need to install Docker to run a simple command? For isolation? No thanks. Virtualenv was created to isolate overwrittkng and installing dependencies.

Also, want to emulate multi-sites on single machine deployment? You need virtualenv.

Docker does solve those problems, even if you and I prefer to use other solutions.

And by the way, you don't actually need virtualenv :) we run multiple webapps on a machine by just installing dependencies in a directory (pip -t) in the git repo, and then adding the appropriate PYTHONPATH in the service's startup config. As long as you don't need multiple versions of the Python interpreter, this works fine.

> Docker does solve those problems

...with a very computationally expensive solution, and without improving other aspects like security.

A systemd unit on a "chroot" can do the same and provide isolation.

Is it really computationally expensive? Containers/jails/zones are essentially chroots "on steroids", isolating things other than the filesystem (networking, hostname, process IDs, users, etc.)

Once built a docker container is not expensive, but the idea with Docker is to create immutable, layered containers and rebuilding every time there is a change. Unlike with nodejs, it's harder to volume mount python packages installed in the docker container and so no one does it.

Change in requirements means rebuilding the container which is a very computationally and IO expensive process. So if you can get away with it virtualenv is better, but putting everything in a container so you can simply ship a container is also useful. It's a compromise.

Rebuilding the container shouldn't be expensive, that's what layers are for.

A layer with your pip requirements being added and then installed is the most expensive part of building a python container so if you change your requirements you invalidate the cache for that layer (and possibly the other layers above).