Add means to declare or opt-out of compatibility (e.g. with Docker)

[amn]

This feature request does indeed concern a problem that has been brought up with issues #175 and #185, stemming from the disparity between Docker and Podman in how each approaches mounting volumes when the volume source denoted by path does not exist.

The issue

The aforementioned disparity is confusing to users like myself who haven't really "migrated" from using Docker in the first place. I have started looking at the Compose spec. and container composition after learning Podman, and I've conversely not used Docker for composition so was not aware of its idiosyncrasies like those described by the linked issues. In other words, I was surprised podman-compose is programmed to [silently] create empty directories when mounting volumes for which source files aren't found. I don't have history with Docker here, after all. In absense of any behaviour learned from the latter, I would naturally expect podman-compose and Podman, by indirection, to refuse to mount non-existing files/directories, and I see no fault whatsoever with it aborting when the volume source does not exist or cannot be accessed. This is in line with how most tools generally behave in similar situations.

My surprise was therefore great when I ended up with composed and running containers where instead of aborting composition and running the service, an empty directory was mounted at a path and the container failed to initialize later, with a confusing "Is a directory" error message.

I understand the dilemma with compatibility, but as far as I can see there's no mechanism to declare or opt-out of compatibility between podman-compose and respectively Docker or Podman. The former has one behaviour, the latter another. Before they reconcile, if they ever will, it could be useful to accommodate users like me (who haven't used Docker) so that we can opt-in or opt-out of some default compatibility mode. This was discussed in PR #194 but it seems the compatibility mode addition was never merged in.

Feature request

A dedicated command line switch named e.g. --compat{,ible,ibility}, declaring desired compatibility, e.g. --compat=docker (do "the right thing" by default for some majority of users) vs --compat=podman, will allow the user of podman-compose to achieve desired behaviour and I expect the changes in the code to be minimal to accommodate the added switch.

The switch will also pave way to develop podman-compose relatively free of having to adhere to a single compatibility profile, and with sensible default value be "transparent" to the user while at the same time empowering every user too.

Alternatives

There isn't currently an "alternative" -- no code path one can force podman-compose to take -- one simply has to accept Docker behaviour as default and instead work around the effect of the behaviour by e.g. "making sure" a given volume source exists, through supplementary checks. Because if for some reason the file does not exist -- and the onus here is on the user of podman-compose -- one invariably ends up with an empty directory mounted, which the container may not have been written to deal with correctly, disregarding whether it was originally a Docker feature or a "bug".