Add a flag to use new Docker Compose command

[karolz-ms]

The latest releases of Docker Desktop include the new implementation of Docker Compose command (docker compose with no dash). Currently our extension only uses the old docker-compose command when running in the local context.

The new command is destined to replace the old one eventually, but at the moment it still may have some bugs, or incompatibilities, and some incompatibilities might never be reconciled. The proposal is then to introduce a setting allowing the user to opt in for the new command, with the idea that sometime in the future we will switch to the new command as a default, and the setting could be then used to opt out of the new command. This should provide the smoothest migration path to the new Docker Compose implementation for our users.

[jnsjunior]

@karolz-ms i know that docker compose without dash is part of Docker Desktop, that has versions for Windows and Mac. I don't know if this command will replace the docker-compose, since linux does not have Docker Desktop. I am using vscode-docker as a linux user, and it is working so good.

[karolz-ms]

@jnsjunior there was a talk about Compose at the DockerCon last week, Nicolas De Ioof was the presenter. He indicated that the https://github.com/docker/compose-cli is the codebase that will be the canonical implementation of Compose in future; also see https://github.com/docker/compose-cli#compose-v2-aka-local-docker-compose

You can install the new CLI on Linux too: https://github.com/docker/compose-cli#getting-started

[sebdanielsson]

I'm currently running docker compose v2.1.0 on Fedora 35 and was about to file an issue before finding this. I would love an option so that I can keep manage my docker compose services with VSCode's Docker extension. Docker Compose v2 has been solid for me👍

https://github.com/docker/compose/releases/tag/v2.1.0

[bwateratmsft]

Related to #3281

[bwateratmsft]

Maybe also related to #3263.

[mjbogusz]

Can't this be solved via the command templates? For me the default for docker.commands.composeUp is:

    "docker.commands.composeUp": [
        {
            "label": "Compose Up",
            "template": "docker-compose ${configurationFile} up ${detached} ${build}",
            "contextTypes": [
                "moby"
            ]
        },
        {
            "label": "Compose Up",
            "template": "docker compose ${configurationFile} up ${detached}"
        }
    ]

so the second one is already compose-v2.

Maybe the main command itself could simply be exposed as a setting (docker.composeCommand), tuning these templates into something like "${composeCommand} ${configurationFile} up ${detached}"? Then the default for the setting would be docker-compose but one could change it to docker compose --compatibility and happily use compose-v2.

[nickleman]

I tried editing the command template to be docker compose instead of docker-compose and that didn't change anything. This should be a higher priority now since Docker Desktop became a paid application and the free alternative (docker in WSL2 with port forwarding on windows and just the docker commandline on windows) only supports the docker compose syntax and not the older docker-compose syntax that is only part of the paid Docker Desktop.

[sebdanielsson]

Any progress on this?

[hermitmaster]

My (temporary) solution was to add a new shell script to my path:

#!/usr/bin/env sh

docker compose "${@}"

[mjbogusz]

My (temporary) solution was to add a new shell script to my path:

The most compatible workaround would be to install compose-switch, which translates changed/deprecated flags. It's still a workaround though...

[jasonestewart]

Can't this be solved via the command templates? For me the default for docker.commands.composeUp is:

I, too, attempted this using the Edit Settings in the VSCode Docker extension settings - which opens up the user-level settings.json file. But as mentioned by others, this doesn't change anything. Is there a different file which must be edited for this to function? If so, it would be helpful for the docs to include that information.

[bwateratmsft]

This is now released in version 1.22 of the Docker extension.