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>
