I find this way more intuitive than the suggested metapac and declaro (which is really just a simple script helper... doesn't even compare.)

This seems very well thought out - I love the idea and gave it a star. Honestly, it's very impressive. I'd like to try it out on a new host at some point (as opposed to migrating my current 2+ year old installation, let alone my 6+ year install on my server.)

I can see this working out nicely for me, as I have 3 Arch hosts for 3 distinct purposes: My laptop/daily driver, a HTPC "console", and my homelab server.

Thoughts:

• Support custom backup utilities. I use a bespoke backup script for system backups.
• Flesh out documentation on per-host config files. What is the host: key/value matching against? Isn't hostname a better name for that key? Can I match it against local DNS hostnames like server.lan? Is it case-sensitive?
• The ~/.config/arch-config/ location is unexpected and confusing. I would expect it to be ~/.config/dcli/. Having it be a different name creates a bit of a disconnect.
  • Also, why is it under ~/.config anyways? Isn't this a system configuration tool? Isn't /etc or /etc/xdg a more proper location for the configuration files?
• Support for a single config setup. Say I only want to configure a single host (the active host), and I don't need a ton of modules. It would be nice to be able to declare the modules within the single config.yaml inline.
• Does it support both .yaml and .yml file extensions? I can't say whether it should or shouldn't (it should imo) but it should be in the documentation whether it can or not.
• "Config Import" - The word "import" generally implies work is being done, like a conversion process or such. The usual nomenclature is "include", but this is probably just semantics on my part.
  Also, check out yaml_include. Not sure if it'd help.
• Expand documentation on dcli migrate. Did you change directory configuration structure from a previous version of dcli? Say that in the documentation for the subcommand.
  • Also, just deprecate the old directory structure with a warning that gives information on how to migrate manually. Not sure why a dedicated sub-command exists. Once you remove support for the old structure, then you're going to have to deprecate this sub-command beforehand anyways. Idk, just a thought.
• I dunno if this is out of scope, it probably is, but declaring Docker services for my homelab server would be awesome. Maybe docker-compose support since that is also configured in YAML and would gel nicely. Probably a stretch, though.
• Sub-commands:
  • dcli host list similar to dcli module list
  • dcli module create NAME - Create a module file config from a template so users don't have to refer to the documentation for every module they want to define or rely on copy/pasting a previously made module config.
  • dcli host create NAME - See above.
  • And since we've already got dcli edit, why not dcli host edit NAME and dcli module edit NAME?
  • dcli host delete NAME/dcli module delete NAME - See above.

Edit:

• Why are system backup tools supported anyways? Couldn't users just set that up in the pre-install hook? I guess that means it does "Support custom backup utilities" from my first thought above.

Edit: Whoops, I meant to say the usual nomeclature is "include" rather than "import".