`container-compose` does not like Docker Compose-style environment config

[purp]

Hi. New guy here. I have a philosophical question, and depending on the answer I might have a bug report.

Q: "Strictly Docker Compatible" or "Help Folks Migrate"?

Spelled out more fully, the philosophical question is: Are we trying to be strictly interoperable with Docker Compose style YAML files, or are we trying to make it easier to migrate to Apple containers by providing a "docker-composer-like" tool? A more concrete related question is: are we okay if container-compose requires Docker Compose-incompatible changes to compose files?

An Incompatible Bit

Thus far, I've identified one incompatibility between docker-compose and container-compose: how we handle environment settings. A simple example: setting some overrides for the nginx:alpine container. Here's what that looks like in Docker Compose style:

services:
  nginx:
    container_name: nginx
    restart: always
    image: nginx:alpine
    environment:
      - NGINX_ENTRYPOINT_LOCAL_RESOLVERS="1"
      - NGINX_ENVSUBST_TEMPLATE_DIR="/etc/nginx/snippets"
      - NGINX_ENVSUBST_OUTPUT_DIR="/etc/nginx"
    ports:
      - "80:80"
      - "443:443"

... which gives you this love note from container-compose:

Error: typeMismatch(Yams.Node.Mapping, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "services", intValue: nil), _DictionaryCodingKey(stringValue: "nginx", intValue: nil), CodingKeys(stringValue: "environment", intValue: nil)], debugDescription: "Expected to decode Mapping but found Node instead.", underlyingError: nil))

... which is fixed by this (environment only, all else is same):

    environment:
      NGINX_ENTRYPOINT_LOCAL_RESOLVERS: "1"
      NGINX_ENVSUBST_TEMPLATE_DIR: "/etc/nginx/snippets"
      NGINX_ENVSUBST_OUTPUT_DIR: "/etc/nginx"

I'm fine with the change; as I said, I'm migrating so I'm not trying to maintain Docker Compose compatibility. But if the project's philosophy is eventual strict compatibility, then this is a bug.

Why Do I Care?

I'm just starting to migrate from Docker to Apple containers, and I'm working to adopt container-compose as the mechanism for this. Thus far, I've been refusing to give up and working around some of the incomplete functionality (like network subnets) and I'm ready to lean in and help make it better in places. I tend towards test-driven development, so I'm spending time understanding what we've got so far and how it's tested. I also write a lot of markdown, so I tend to use it when I can.

At the moment, I'm working on cleaning up some small things like where container-compose emits a hard-coded "docker-compose.yml" string, as well as many comments and a bit of the README where we refer to these, and the pedant in me wanted to be sure I changed things to the right way we should think and talk about them. And here we are.

It also felt like a small bit of good I could do while adopting, and it feels like it's related to a few issues like #33 , #36, and maybe #63. So I'm adding a test that breaks if we talk about the wrong filename, and that incidentally tests that we're using the right file with --file ... so we'll have a test soon, then I'll look at cherrypicking some of #36 or #63 into a PR to fix it.

Thanks for reading. I'm usually more terse. This felt like it needed details, so I added some.

[Mcrich23]

Hi @purp. Thanks for asking! My view on Container-Compose is that the goal is mostly a drop in replacement. Sometimes, there are quirks in operation or decoding which forces changes to the file. To maintain compatibility, the solution has been to have preferred support for a compose.yaml file and fallback to docker-compose.yaml when that is not present.

This is a perfect use/fix for the issue that you are encountering.

[purp]

Got it, and makes sense. Feels like four categories to me:

1. Things that work exactly the same in both. Nuff sed.
2. Things that work in a Docker Compose file but not a Container Compose file. These may be as-yet-unimplemented things, or they may be things we never intend to implement. Some docs on the former would be nice; docs on the latter feel more important just so folks can know what they're getting themselves into.
3. Things that work differently in a Container-Compose file than a Docker-compose file. For any of these that are likely permanent incompatibilities, we should document and message about them clearly. For any that are temporary inconveniences along the road to a more perfect implementation, we should have an open issue about it so folks can find it and perhaps opt to fix it.
4. Things that are only present in a Container-Compose file. I don't have anything in this category yet, but it would be things we allow in order to take advantage of some interesting, unique capability in Apple containers that does not have an analog in Docker.

This thinking might be worth turning into some documentation somewhere, but for now it's here and searchable.

[purp]

Meanwhile, this issue is definitely in Category 3. If we think this is permanently incompatible, we should close this issue, else it's here for someone who wants to tackle it.

[Mcrich23]

I fully agree. I think documentation is a massive thing in this regard that AI cannot quite get correct. I do not have time to gather such documentation, but would be incredibly grateful if you or someone else would.