File Sync format specification: maybe don't have user data in the key part

[thomas-riccardi]

#1039 added a key: value map under sync in the skaffold format.
The key is a local glob pattern, the value is the destination directory.

Example:

    sync:
      '*.py': .

Coming from k8s it is unusual to have user data as keys; it surprised me.

Digging into k8s design doc, we have:
https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#lists-of-named-subobjects-preferred-over-maps
There are whole discussions linked from there, notably about

• readability (mostly in case of subobjects though)
• merging definitions, which may or may not be of concert for skaffold

It lists exceptions to this though: "pure maps [...] as opposed to sets of subobjects".

I suppose if we later want to enrich the format with subobjects it would make things harder with the current format.

I am not (yet) familiar with all the skaffold format, I don't know if there are other cases like that, I couln't find any.

Question

Shouldn't we forbit storing user data as keys?

Suggestions

Either go full sub-object like in k8s:

    sync:
    - localPattern: '*.py'
      destination: .

(better names are welcome)

Or maybe support lighter format with string:

    sync:
    - '*.py:.'

But I'm not sure it's a good idea: it doesn't seem that much readable...

[r2d4]

I think this is the right decision. I initially tried option 2 but rejected it for the same reason. Subobjects would also make #1166 easier to implement.

I’m all for subobjects, even at the expense of brevity.