Could services be a map?

[joshwget]

Any reason why the second syntax couldn't be used? Maybe it's a matter of preference, but I think a map would work well for this (also resembles Docker Compose a bit more).

version: 0.1-dev
services:
- name: helloworld
  containers:
  - image: tomaskral/nonroot-nginx
    ports:
    - port: 8080

version: 0.1-dev
services:
  helloworld:
    containers:
    - image: tomaskral/nonroot-nginx
      ports:
      - port: 8080

[concaf]

Hey @joshwget, we have had similar discussions on #105 and elsewhere, and we decided that the OpenCompose spec should take control of all the keys in the spec to maintain consistency and to allow extending fields. e.g. - we recently refactored environment variables from -

env:
- a=b
- x=y

to

env:
- name: a
  value: b
- name: x
  secretRef: <secret>

The latter allows us to add more fields like referring to a secret in the env variable, without breaking the consistency, in the sense that, throughout the env definition, all the keys are in control of the spec.

Thoughts? Would love your input on this :)

[joshwget]

If I'm reading things correctly it seems like the root reason is to avoid polymorphic fields, like env would be if both of the following syntaxes were valid.

env:
- a=b

env:
- name: x
  secretRef: <secret>

I'd argue this is one of the key strengths of Docker Compose. It allows a lot of the boiler plate to be avoided when it's not necessary.

[kadel]

@joshwget yes you are right. But having multiple ways of writing things can also sometimes lead to confusion. One of the rules that we are trying to follow is that OpenCompose has only one way of writing things. We might try to add shortcuts like this in the future, but right now we will try to stick with only one way.