> Personally, I find there are many nice properties from doing things the
> way it's currently done in Guix. For one, the configuration records are
> documented and can be found in the `info guix` manual, quickly
> accessible via the Texinfo indexes (i). It's also human-readable in
> your config.scm file.
true, but the question is the final balance.
actually, this is exactly the point where the biggest downside is for me: the
guix side of the config renames the fields to stick to the guix naming
convention, thus introducing unnecessary friction in searching the docs and
editing the config, and it also gets out of sync with upstream. and this is
just the user-experience side of it, without considering the effort it takes to
implement the guix wrappers.
in *some* contexts it may be worth it. where e.g. scheme gives a lot of
leverage (see Carlo's example of service extensions), or for old daemons with
stable config code, etc.
but indiscriminately creating/expecting guix wrappers for every service is most
probably a net loss.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If you shut up truth and bury it under the ground, it will but grow, and
gather to itself such explosive power that the day it bursts through it will
knock down everything that stands in its way.”
— Émile Zola (1840–1902)
