How does this project relate to github.com/docker/compose?

[nickatsegment]

It probably bears mentioning in the README at least.

Based on name alone, I assumed it is a successor to docker-compose. Apparently that is not the case; this docker compose is for deploying to cloud providers, and docker-compose is for local testing?

Also confusing is that the Releases tab for this project is a binary called docker that is apparently identical (probably modulo code-signing; they reference the same git commits) to the one in Docker Desktop (for Mac):

$ docker version
Client: Docker Engine - Community
 Cloud integration: 1.0.2
 Version:           19.03.13
 API version:       1.40
 Go version:        go1.13.15
 Git commit:        4484c46d9d
 Built:             Wed Sep 16 16:58:31 2020
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.13
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       4484c46d9d
  Built:            Wed Sep 16 17:07:04 2020
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.3.7
  GitCommit:        8fba4e9a7d01810a393d5d25a3621dc101981175
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
$ ~/Downloads/docker/docker version
Client: Docker Engine - Community
 Cloud integration: 1.0.2
 Version:           19.03.13
 API version:       1.40
 Go version:        go1.13.15
 Git commit:        4484c46d9d
 Built:             Wed Sep 16 16:58:31 2020
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.13
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       4484c46d9d
  Built:            Wed Sep 16 17:07:04 2020
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.3.7
  GitCommit:        8fba4e9a7d01810a393d5d25a3621dc101981175
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Interestingly, the issue template for this project seems to hint at the ability to deploy locally, like docker-compose does, but I cannot seem to get that to happen (seems to be by design).

**Additional environment details (AWS ECS, Azure ACI, local, etc.):**

I created a forum post as well, with some slightly different info, since this is a cross-project problem.

[gggeek]

The situation is probably confusing because of the rapid pace of change, but I also am quite lost with the info currently available.

• will docker-compose be phased out in favour of docker compose ?
• why is docker compose distributed as part of Docker-4-Desktop instead of being distributed as a standalone plugin for both Docker-4-Desktop and Docker-CE?
• does docker compose support the build tag in d-c files, or only image? If the latter, is support for build planned at all?
• which other limitations apply when running docker compose compared to docker-compose?

[nickatsegment]

Just some other interesting data points:

docker/roadmap#33 (started Mar 6 2020) has a prefix [Docker Compose] and it refers to docker-compose, not compose-cli.

docker/roadmap#15 (also Mar 6 2020, coincidentally) is about moving docker-compose to Go, but strangely makes no mention of docker/compose-cli.

Considering both are authored by our assignee @nebuk89 I await with bated breath what they have to say :)

The 2.4.0.0 release notes contain updates to both compose-cli and docker-compose but only just barely manages to not refer to them with the same name:

Docker Compose CLI - 0.1.18, enabling use of volumes with Compose and the Cloud through ECS and ACI.
...
Docker Compose 1.27.4

[nickatsegment]

@gggeek

The situation is probably confusing because of the rapid pace of change

I mean sure, but having two components with identical names that are subtly incompatible (and both are v1.x) is kind of nuts.

[ndeloof]

I can understand this is highly confusing :P
docker/compose-cli is "a Compose specification implementation" which focus on deploying a compose application to various platforms. We support Amazon ECS and Microsoft ACI and I'm working on a "local" implementation (https://github.com/docker/compose-cli/tree/compose-in-go).

Compose-cli is not intended to be a drop-in replacement for docker-compose, even it tries to mimic it's predecessor so users don't have to learn from scratch. Consider it a CLI to bring your compose.yaml file to a higher level of deployment compatibility. docker-compose can and will still be used for various use-cases that won't be covered here.

[nickatsegment]

So to be clear, users should expect to have two commands in Docker Desktop for the foreseeable future:

• docker compose
• docker-compose

At some point in the future, docker compose will have local support and will then be a reasonable (if not drop-in) replacement for docker-compose.

Can we get a statement about this in the projects' READMEs? Or even better, in docs.docker.com? I came to compose-cli because I saw a 1.x release in Docker Desktop's changelog; I would expect other users to have the same confusion.

[al-dpopowich]

Add me to the "confused" group of users. Mostly, I'm disappointed by the name overlap. How unfortunate that these two similar, but as of yet, incompatible tools share the same name, e.g., searching for help on docker compose usage inevitably returns meaningless hits for docker-compose.

My Kingdom for going back in time and naming this docker deploy or anything but docker compose.

[BretFisher]

@al-dpopowich The reason they are named this same may come from the fact they both focus on doing things with compose spec yaml, and you can mostly use them interchangeably on the same compose file. They are now both standardized on the compose spec and neither defaults to v1, v2, or v3 compose yaml files anymore.

You can see by this feature list, that the new docker compose has nearly all the features and commands of the old python docker-compose and also adds a bunch of new features, like the ACI/ECS integrations and new commands like docker compose ls. IMO, each month I use the new docker compose, it's more feature complete and does more things than the python docker-compose. Bugs are still getting squashed as we find edge cases, but I'm able to use it daily in a team as a drop-in replacement.

docker-compose in Docker Desktop still points to the original python-based CLI, so docker compose isn't yet changing any workflows that expect to use the traditional python tool.

I agree the readme is super basic and not clear about the purpose or roadmap for this tool. I'll see what I can do to help with that.

[ndeloof]

project's README now make it clear this repo is hosting code for Compose v2, which will eventually replace docker-compose

[piksel]

From the docker compose docs, you get the impression that the install_linux.sh script would install V2/docker compose, but it just installs the latest v1.x (which I still have no idea what it even does).

I finally got it working by curling the latest pre-release into ~/.docker/cli-plugins/docker-compose as hinted in the README, but it's not entirely clear why "installing manually" is necessary.

Perhaps some syncing/clarification is needed between docs?