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.
Read COMPOSE_FILE from env and use it if it is set. Default is still
docker/local/docker-compose.yaml.
BREAKING CHANGE: Removed docker subcommand. Added deprecation notice to
compose subcommand.
Unified expected output to always eprintln so outputs can be piped to
other processes. Added debug_eprintln and switched all occurances of
debug_println.
Fixed bug where restore commands were called inside pg_isready loop.
Made CommandBuilder::build public. Redirected stdout for pg_isready
calls to /dev/null via Stdio::null().
Fixed issue where arguments passed to `compose stop` weren't passed to
the underlying command. Added pg_isready call between each command call
in restore script.
Removed `completion` command in favor of compile time completion
generation. This tool will only be build from source for the foreseeable
future so this makes sense for now.
Exec is new command scoped under compose. It allows sending commands
directly into appserver container. I will make this
customizable/controllable in the future.
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.
Implemented basic wanted functionality for postgres subcommands. We
currently assume that postgres is running in docker-compose project in a
service named "postgresdb". This could be looked at and changed at some
point in the future.
Allow for starting just some of the containers. This will be needed for
implementing postgres::import where we'll need to stop all containers
and then only start postgres container.
Implemented basic wanted functionality for docker compose subcommands.
We currently assume that docker-compose.yaml file is located in
local/docker/ folder.
Made initial command scopes
d -> docker related commands
dc -> docker compose related commands
dj -> django related commands
pg -> postgres related commands
