Consider version check as "docker-compose up --wait" is only supported in v2

[sarim]

Right now with docker-compose v1 it silently fails if run with "symfony server:start -d". messenger_consume_async or any worker dependent on docker service's env variables fails to start. But symfony-cli just shows "[OK] Web server listening"

1. If docker_compose key is defined, then check docker-compose version and explicitly fail whole server:start command if version requirement is not met.

2. Consider supporting docker-compose v1. This is kinda pointless, more context below. A far fetched solution would be ditch docker-compose altogether and use libpod api via docker/podman's unix socket directly. But it'll probably be out of scope for symfony-cli.

I'm using podman with docker-compose v1. For people using docker itself, its no brainer to update to docker-compose v2. But for podman docker-compose v1 is the only option, though its depreciated. (docker-compose v2 seems to be working with podman despite apt dependency on docker.)

I can put together a quick PR for version check and fail if maintainers agree.

[tucksaun]

Hi there,

Given that this integration is optional and that docker compose v1 is deprecated I'm not sure that it really makes sense to put a lot of effort into this.

But if you are willing to work on a PR and that it does not require too much work or changes then why not.

[sarim]

@tucksaun in debian and ubuntu default repo its still v1. So apt install docker-compose installs the v1 version. This was the case in all of my machines. After manually installing compose from https://github.com/docker/compose/releases it was fixed for me. It is a rare use case because I'm using podman as container engine, not docker. As majority of people will use docker and docker's repository, so they won't pull from debian/ubuntu main repo.

But if you are willing to work on a PR and that it does not require too much work or changes then why not

Okey :) I'll check if it can be done with little code change.