ConfigV2: Mixins & Includes

[jkellerer]

The recent merged mixins feature has the ability to share pieces of configuration also when spread across includes like in the following example:

profiles.yaml

version: 2
includes: '*.inc.yaml'

profiles:
  default:
    backup:
      use: exclude-hidden

macos.inc.yaml

version: 2

profiles:
  default:
    backup:
      use: exclude-macos

shared.inc.yaml

version: 2
mixins:
  exclude-hidden:
    exclude...: ['.*']
  exclude-macos:
    exclude...: ['.DS_Store']

At the moment, after processing all includes, the resulting default profile is:

profiles:
  default:
    backup:
      exclude: ['.DS_Store']

The property exclude is not ['.*', '.DS_Store'] because use properties are overridden and only the last use really applies. For this example with a single property this would also happen when declaring exclude directly inside profiles.yaml and macos.inc.yaml but if different properties are specified mixins would also only apply the last use while includes would merge.

Question

Would it make sense to apply all use properties in order to have a similar merging behaviour as with includes (with the addition to be able to append to lists). This would require a change in that all occurrences of use need to be collected from every include and get applied after all includes have merged.

[ryszard-suchocki]

What about change the "property" use: mixin to the list use: (new line)- mixin ? Is it behave same?

[jkellerer]

Yes behaviour would be the same, it doesn't matter if it is list or string value. I think the case I described here must be fixed to not get unexpected results (results that differ from using plain includes only).

[creativeprojects]

This is very good point. But we can go even further in the inheritance madness: what should we do if a mixin is redefined in an include?

Let's imagine you also have a mixin exclude-macos in the file macos.inc.yaml?

• should all the include files be resolved with their own mixin first?
• or should we only resolve them all in the profile at the end

[jkellerer]

Had thought about this case.. it should work like this:

• Combine all includes, but collect use individually from every include before it gets overridden
• Parse all mixin
• Apply all use (in declaration order)

And to let it work with inheritance the following should work (though I'm not yet sure about inheritance chains):

• Delay apply of use for the current profile until inherit was applied. This should allow to append to list defined in the parent and should not cause other side effects.
• Would require to implement inherit as recursive map operation (instead of multiple config structure parsing).

[jkellerer]

The PR addresses all issues mentioned here and even allows list append/prepend for normal inheritance (in v2 configs)