systemd
Refactor everything to make file-based configuration primary, cmdline args secondary
In the man page, and in the code, the cmdline options are the most exposed. But that seems backwards: the user can hardly put 50 options on the commandline. I think we should invert the code and the docs to make the config file options the "primary key".
In the man page:
Command Line Parameters
--foo
...
Command Line Parameters and their Settings File Counterparts
--foo Output Foo=
...
becomes
Settings
[Output] section
Foo=
--foo
...
Also, I would like to write the whole configuration, i.e. the args variable, to the manifest as json (for #768). But I think it'd be better to rearrange the code first. Not everything should be saved to the manifest, and I think the data structure that we have should also provide a way to annotate what should be stored there. And then there should be an automatic way to populate args from a saved manifest. In the proposed man page structure above we'd add another line that Output.Foo becomes ["output"]["foo"] in the manifest.
This will also make the addition of new things easier: there will be one place to modify in the docs, and one place to modify in the code.
I'll work on this, but I want to gather some feedback before I start.
I like the idea, but I'm not sure that files should trump the CLI. In my view files should provide the the baseline and the CLI should be the escape hatch to quickly explore "Is this the option I need?" without having to touch a file, but maybe I'm not fully understanding your reasoning. From my point of view, changing the man page to focus on the file based config would be the central thing.
Refactoring args is something I've already noodled over quite a bit with the splitting out the distributions project, since it's weaved through everything. It would be great if it could be split up a bit into logical chunks, e.g. maybe everything concerned with the (partition) layout of the image going in one bucket and so on.
I'm not proposing any changes to behaviour. Just a refactoring of the code and docs.
Not everything should be saved to the manifest, and I think the data structure that we have should also provide a way to annotate what should be stored there.
Might be worth looking into https://docs.python.org/3/library/dataclasses.html#dataclasses.field to annotate which fields should be stored in JSON and which shouldn't.
But yeah, making the config the source of truth sounds like a good way to go. Like @behrmann said, I use CLI options more when trying stuff out rather than as a primary configuration mechanism.
@keszybz With your documentation rework and the recently merged configuration rework, I think this is more or less fixed now? We don't yet support writing the config to the manifest but I think that should be a different issue.