Argument values as `yaml/json`?

[achilleas-k]

Customizations as k=v on the command line can get messy when we need structured data. Should we consider customizations being fed into a call as a yaml or json?

[supakeen]

Currently in osbuild-mpp they're passed as -Dkey=JSON where JSON can be any valid JSON. My idea was to keep that.

We could expand on it with a -Dkey=@file where @file would open file and expect it to be JSON.

[mvo5]

Fwiw, I agree with @achilleas-k here, but I also feel this is too much implemenation detail for the existing spec, maybe just:

diff --git a/doc/directives.md b/doc/directives.md
index 9e55670..b405b9f 100644
--- a/doc/directives.md
+++ b/doc/directives.md
@@ -178,20 +178,20 @@ otk.meta.kiwi:

 ## otk.customization

-Customizations are conditional blocks that receive separate input through
-`otk compile -Cname=data`, a customization is considered to be active when it
-is passed data. If a customization is passed multiple times then the `defined`
+Customizations are conditional blocks that receive separate external
+input. A customization is considered to be active when it is passed
+data. If a customization is passed multiple times then the `defined`
 block is replaced multiple times, once for each data input.

and we worry about how it's passed later? My gut feeling is that passing just a config file in (or feed in via a pipe) but I don't know too much about the upper service layer to really judge for now?

[supakeen]

After speaking with CentOS Automotive today they'd really like the @somefile syntax for arguments, they run into issues with quoting regularly.