Open jnweiger opened 1 month ago
I am also using the symlink trick quite extensively... Any solution for docker compose v2 please? :\
Maybe I could live with a new COMPOSE_PROJECT_DIRECTORY
env var for --project-directory
option, because that seems to work pretty well.
For now, I settled with
export COMPOSE_FILE=$(readlink -f /path/to/symlink/dir/docker-compose.yml`
or
cd /path/to/symlink/dir
export COMPOSE_FILE=$(readlink -f ./docker-compose.yml)
since -f compose_file
is working as well.
It would still be nice to have the COMPOSE_DIR env var available. Or just fix compose to take eval the symlinks.
Description
My docker-compose.yml lives inside some github checkout subdirectory. As an admin, I make a symlink 'o' in my home, that brings me there. changing directory to the real path, I run
docker compose up -d
Then, when using the symlink, docker compose commands either silently do nothing, or produce an error. When using the real path, the same docker compose commands work just fine.(Also the other way around: You always have to use the symlink after starting with
cd ~/o; docker compose up -d
)docker compose ls
shows which variant works.Expected behavior:
It should make no difference, how I navigated my shell to the project directory.
Steps To Reproduce
Workaound
In bash, use
set -o physical
Compose Version
Docker Environment
Anything else?
I can see several usages of EvalSymlinks() in pkg/compose/watch.go, but none in e.g. cmd/compose/compose.go
Please note that
filepath.Abs(".")
happily constructs absolute paths with unresolved symlinks. That's a pity, as it is often used. I tested the symlink behaviour with:My assumption is that golang's filepath.Abs() happily relies on the PWD environment variable from the shell, which is weird.