Our goal with having Docker in the first place is to make it easy to
deploy the application. 'just migrating' is a good idea for that goal
in general, but the more so because running migration commands when
the container isn't running yet, while the container refuses to run
without them having run putch you in a catch-22.
(the above may not be strictly true when you run with a database that's
external to your image, i.e. with mysql, because then you can use 'run'
rather than 'exec', but even that feels a bit 'wrongish', because run
starts a container that is then left around for `docker ps -a` to see)
for sqlite containers it's even more pressing, because the writes-to-db
go to different databases for each of the incantations of run (including
server-start). Even if I get this to work (I can't find the solution
in 15 minutes) it will be so clunky to be unworkable.
Theoretical concerns about not migrating on-server-start (but rather,
as part of some CI/CD script or something) will have take take a back-seat
to the reasoning above... if they even hold up at all).
This is more canonical with stuff 'elsewhere on the internet'
we already did it behind-the-scenes for 'recommended gunicorn', so the
harmonization is in having the same default for the rest.
* I'd rather harmonize with "the docker way" than with my own recommended setup
* slim: expectation is that this is smaller (not checked)
* this is a 2-stage build (slim has no gcc, needed for mysql)
* PEP668 does not apply here ("externally managed"), which leads to
* better ergonomics: no env/bin/some-command
