> Sometimes you can't reuse a docker-compose file shared by a third party project straight away without adaptation

So not a drop-in replacement then...

4 points:

1. Most of the issues I had that forced me to adapt a docker-compose was because I was using podman rootless and most people build docker-compose file with docker running as root in mind. mostly to have access to privileged ports. I guess running podman under root would have solved this but one of the reason I switched to podman in the beginning was for the rootless capability. In a way this wasn't much different than modifying a deployment to work with docker in rootless mode.

2. part of the appeal of using podman is its compatibility with kubernetes yaml file so you tend to quickly switch away from docker-compose anyway. Also for self hosting, the systemd approach was more elegant, even before the quadlets support.

3. One would argue that docker-compose != docker/moby engine.

4. docker-compose has introduced breaking changes in its history which meant adapting your compose file or add flags at runtime such as `docker-compose disable-v2`

EDIT: adding points

Overall fair points, though I disagree with 3 since it's been integrated sufficiently (not a separate install and not a separate executable).

> 4. docker-compose has introduced breaking changes in its history

...until the point when they resigned any notion of versioning. You can't have a breaking change if you don't promise a stable behavior, see? /s

Not many people noticed that the top-level

    version "3.9"

has no effect anymore. "It is only informative", the current spec says. Your old docker-compose.yaml files spew errors as soon as they go out-of-sync with the master branch (classy!) of the spec repo.

Tbh, with the changes in the last few versions, you can't reuse some compose files even between different versions of docker, so... they're actually pretty comparable there.