My reasoning is twofold:
1. a count of 1 is actually probably "enough for many setups" because ingestion
is very fast anyway (just store the file); while the lower memory-footprint
that comes with having fewer workers means that adoption of Bugsink will be
easier.
2. tuning the variable is going to be less annoying if there's no default that
might override "in the wrong direction" (i.e. the interaction between
`WEB_CONCURRENCY` and `GUNICORN_CMD_ARGS`)
See #101 (where the concept of customizability was discussed, though not the
present idea of chaning the default).
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
Klaas van Schelven