Project name derived from config file path, not CWD

[brandon-leapyear]

Description

The docs say that

If you supply a -p flag, you can specify a project name. If you don’t specify the flag, Compose uses the current directory name.

But doing docker-compose -f foo/docker-compose.yml will use foo as the project name, not the current directory. Either this is a bug that needs to be fixed, or the docs should be updated.

Steps to reproduce the issue:

1. mkdir mydir && cd mydir
2. docker-compose -f foo/docker-compose.yml

Describe the results you received: Containers named as foo-...

Describe the results you expected: Containers named as mydir-...

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version v2.2.3

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1)
  compose: Docker Compose (Docker Inc., v2.2.3)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 14
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 2.429GiB
 Name: docker-desktop
 ID: LFLY:RUPL:KOEB:6UJT:5OFZ:PWES:G342:AGHI:GC7P:DXJD:6Z5R:F65U
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

[alexandernst]

Maybe caused by https://github.com/docker/compose/commit/65ed8cf4c29925c387d51906ebd260627d3bd20b ?

[brandon-leapyear]

:sparkles: This is an old work account. Please reference @brandonchinn178 for all future communication :sparkles:

---

Yes, that seems correct. I'm not sure that commit is the correct solution. Our usecase is that we want to put the docker-compose.yml files in a subdirectory, so we can extend them with each other and keep them all in the same place, which doesnt seem like an uncommon usecase.

A more canonical solution (used by tools like git or tar) would be to have a -C flag to set the cwd

On Mon, Mar 21, 2022, 11:13 AM Alexander Nestorov @.***> wrote:

Maybe caused by 65ed8cf https://github.com/docker/compose/commit/65ed8cf4c29925c387d51906ebd260627d3bd20b ?

— Reply to this email directly, view it on GitHub https://github.com/docker/compose/issues/9267#issuecomment-1074248308, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGUC75PXIIDSFGFHI2JE3NLVBC335ANCNFSM5QOGZC4A . You are receiving this because you authored the thread.Message ID: @.***>

[laurazard]

@brandon-leapyear thanks for the report!

I understand the issue you're reporting, but could you better explain your usecase? The way I understand it (extending compose files with each other), you can accomplish that by having multiple of them in the same directory (using different names, such as x.yaml, y.yaml). You can then run those with compose -f [file-name.yaml], and if you need them to be considered different projects you can use the -p flag when running compose.

[brandon-leapyear]

:sparkles: This is an old work account. Please reference @brandonchinn178 for all future communication :sparkles:

---

Sorry, I'm not quite sure why I shared that use-case 😛 But the relevant aspect of the use-case is this: we have a subdirectory that contains all of our Compose files, I use git worktrees a lot, so I'll have the same repo checked out in multiple branches. Currently, the project name is always subdir regardless of what worktree I'm in, when the project name should instead be the directory of the repo (which is different per worktree).

We're currently working around this by explicitly setting COMPOSE_PROJECT_NAME. The current behavior really isn't that bad, the docs are just inconsistent with the behavior. Fixing the docs alone would be fine, although I do think the better fix would be to use CWD instead of dirname $compose_file

[laurazard]

Ahhh, that's fair! We can discuss that, or at least changing the docs for sure.

[ndeloof]

docs has been updated with a better description for the (complex, sorry, legacy...) logic used to define project name https://docs.docker.com/compose/reference/#use--p-to-specify-a-project-name

[luciangabor]

I don't know exactly since when, but it's been a while since it's possible to define the project's name as a top-level element in compose.yaml ... and this allows having more ... well-defined names than solely relying on a directory name:

docker compose -f <(echo name: whatever) config
name: whatever
services: {}

(I remember first reading about this in the compose specs ... specs, but I also remember not being accepted as input, for a while ...)