ahab guessed that the django service is called django and the postgres one db,
falling back on AHAB_DJANGO_CONTAINER and AHAB_POSTGRES_CONTAINER. The standard
project layout happens to agree, but nothing enforces it, and a stack naming
them web and database could not use ahab without setting both variables.
One `docker compose config --format json` call, roughly 120ms, resolves the
stack even while it is down, and the services are identified from what they
are rather than what they are called:
- postgres is the service whose image is a postgres flavour, matching postg,
timescale, pgvector or citus. Nothing else counts.
- django is the service that both builds an image and has
DJANGO_SETTINGS_MODULE in its environment. A celery worker sharing the same
build and env_file matches too, so published ports break the tie: the service
answering requests wins.
Neither guess is allowed to be wrong quietly. No match, or two candidates that
cannot be told apart, is an error naming the services it looked at. There is no
variable to fall back on: both container variables are gone, along with the
guessed defaults they backed up, so an ambiguous stack is fixed in the compose
file rather than worked around per developer.
Every service lookup goes through these rules, so `compose exec` and the whole
django group agree on which container they mean.
POSTGRES_USER and POSTGRES_DB come off the detected service, so dropdb,
createdb, pg_restore and pg_dump stop assuming the role and database are both
literally `db`, falling back to that only when the service declares neither.
Note that env_file entries are merged into a service's environment, so
POSTGRES_* is not safe for identifying the database service: one such line in a
project's .env would make the django service match as well. That is why
identification uses the image and only credentials use the environment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Read default postgres compose service name and default django compose
service name from env variables.
AHAB_POSTGRES_CONTAINER - defaults to `appserver`
AHAB_DJANGO_CONATINER - defaults to `postgresdb`
Default values are there for 100% backwards compatibility.
Unified expected output to always eprintln so outputs can be piped to
other processes. Added debug_eprintln and switched all occurances of
debug_println.
Implemented custom command builder with nicer api suited for my needs.
Also returned error if there are no containers in
`scripts::postgres::get_containers`.
We just called `manage` inside docker instead of
`exec appserver python manage.py`. Now we make assumption that django
app is running in docker-compose in service named `appserver`.
While fixing this bug we also refactored for `shell`, `makemigrations`
and `migrate` to all call `manage` under the hood to avoid repeating code.
Made initial command scopes
d -> docker related commands
dc -> docker compose related commands
dj -> django related commands
pg -> postgres related commands
