dockercompose: use "docker compose" before docker-compose

[nicksieger]

No description provided.

[nicks]

a couple questions:

• do we need to worry about docker.exe?
• the logic here is: "if docker-compose doesn't exist, assume 'docker compose' does." That will lead to this error message:

$ docker compose
docker: 'compose' is not a docker command.
See 'docker --help'

which seems like a bad outcome

[nicks]

according to this doc:
https://docs.docker.com/compose/#compose-v2-and-the-new-docker-compose-command

docker compose is the preferred form, so seems like we should try that first.

[nicksieger]

• I removed the ".exe" appending code because it doesn't seem to be needed anymore (with go 1.18 on windows)
• Yeah, I think that makes sense. Seems like we might want to just run the version command when we make the client so that we can see which form to use.

I also have some issues with the tests so I'll have another round to look at soon.

[nicks]

ok, i might defer to @milas on the logic here, i remember the decision tree being fairly complex

[milas]

Yeah, I think docker compose is the recommended way going forward.

It's worth mentioning that the shim actually does some flag translation: https://github.com/docker/compose-switch/blob/2fe0b713c6839e86239e4930b98fe94f3c68f4e2/redirect/convert.go#L26-L64 - I think that --verbose -> --debug might be the only one that would cause trouble, but tbh I'm in favor of not passing that flag at all because Compose emits a LOT of internal debug logging.

[milas]

As for decision tree, I think at this point it's safe to prefer docker compose and fallback to docker-compose.

(When V2 was in early preview, we'd prefer docker-compose-v1 which is what the shim would conditionally invoke based on preferences, so we used it explicitly, but that isn't necessary anymore.)