Accept Argument(s) for --compatibility in v2 and Beyond

[jcburley]

The --compatibility option is required to ensure V2 still uses underscores, instead of hyphens, when composing container names. (This change broke quite a number of our scripts; Docker Desktop apparently is semi-randomly changing some of our docker-compose commands to be v2 without our noticing until we hit such failures.)

At some point, especially in light of #9060 and such, it might be desirable for this option to accept arguments, with the default being the (only) current behavior (call it v1 or hyphen or something?).

Then, other compatibility modes could be specified as (say) a comma-separated list, e.g. --compatibility interpolation,dot (which would exclude using underscores, rather keep the new behavior of using hyphens, as separators in container names, while enabling those other two compatibility modes).

Note that we tried (in our scripts) sussing which separator to use based on whether v1 or v2 was running; but that recently broke, in that v2 reverted to using underscores, and it's not clear why (since we weren't passing --compatibility nor could see anything in the environment like a COMPOSE_COMPATIBILITY variable). This whole area could use better, clearer, documentation.

Finally, a docker-compose command to list the configuration options (and/or relevant env vars) would be helpful when debugging stuff like this.

[dellagustin-sap]

Hello @jcburley , have you tried disabling v2 for docker-compose with docker-compose disable-v2 to ensure that docker-compose still used v1? Reference: https://docs.docker.com/compose/cli-command/#install-on-mac-and-windows

[jcburley]

Hello @jcburley , have you tried disabling v2 for docker-compose with docker-compose disable-v2 to ensure that docker-compose still used v1? Reference: https://docs.docker.com/compose/cli-command/#install-on-mac-and-windows

That's good to know about, but it doesn't seem like the right solution for our test scripts, which we'd like to continue running in both v1 and v2 environments, without having side-effects such as forcibly downgrading a user or machine from a v2 to a v1 experience.

[dellagustin-sap]

It is a bit hacky, but you could detect the version of docker-compose in the beginning of the script, downgrade to v1 if necessary and upgrade it again to v2 at the end. Again, hacky, but given the current options, it could work.

[jcburley]

It is a bit hacky, but you could detect the version of docker-compose in the beginning of the script, downgrade to v1 if necessary and upgrade it again to v2 at the end. Again, hacky, but given the current options, it could work.

Hehe, it'd certainly work, but might mysteriously break other things that happen to be running in parallel! Or leave things in an unexpected state if the script was interrupted or exited early.

[dellagustin-sap]

Hehe, it'd certainly work, but might mysteriously break other things that happen to be running in parallel! Or leave things in an unexpected state if the script was interrupted or exited early.

Good points.

[dellagustin-sap]

One remark on your proposal for having a granular control over compatibility features, that would only work if these compatibility features are implemented in v2, which the maintainers may decide not to do (it is a new major version, it may have non backwards compatible features at the end). One alternative for your use case (usage of docker-compose on scripts) would be a command line option to specifically choose v1 or v2 when running docker-compose (e.g. --version=1 or 2), so that scripts could have more control without switching it back and forth as I suggested in https://github.com/docker/compose/issues/9061#issuecomment-1004614932.

[jcburley]

Thanks for the idea! However, the more I learn about our use cases, the more I think (hope?) we'll be eliminating these older test scripts that rely on independently computing the container names, probably in favor of running the tests entirely within a container in a way that captures logs and stuff like our scripts currently do. That'd solve at least the issue at hand for us.

We might even, when building our containers with docker-compose, install both the (latest) v1 and v2 versions, using suffixes as in docker-compose-v1 and docker-compose-v2, so our container "clients" can specify which they want, if there appears to be a genuine need for it. (We're using a similar technique for another executable, and it's working quite well.)

Re docker-compose itself, and really for any sufficiently complicated and evolving executable that'll be widely used in scripts, it's worth considering offering a --compatibility[=mode1,mode2,...] option.

Early versions of the tool (and this could be backported to the v1 series of docker-compose) would ignore the string of "modes", if not the entire --compatibility option, entirely.

Subsequent versions that introduce specific modes would recognize and handle those, but ignore any they don't recognize.

This wouldn't be quite as "sophisticated", perhaps, as using version numbers; but in cases where version numbers are already in abundance, referring to things like configuration files and such, it might be easier to implement, maintain, and document.

In this particular case, if v1 ignored --compatibility[=anything], and v2 implemented --compatibility=underscores (or some such mode name that would best describe what changed) while ignoring any other mode specifiers (in the comma-separated list or in subsequent --compatibility= options on the command line), a script could reliably specify that latter option and be assured of always getting container names with underscores, not hyphens, separating their components.

This is probably overkill, though; I haven't yet had enough experience with Docker to opine on that.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.