On 2023-12-26 at 15:56+01:00, Ricardo Wurmus wrote:
> On 2023-12-26 at 14:53+01:00, Sergey Trofimov wrote:
> > - adding it to guix increases maintenance burden: new versions
> >   could add or remove config options
>
> This is why there should be automated tests.
> There are too few of them.

This is easier said than done.  A program could require a display
and audio server so it's not trivial to run as CI, and even for
contributors and maintainers, some configurations could only
be tested with the program's input file, and even then
some tests would need to measure imprecise things like
text colors which is aliased.

On 2023-12-26 at 14:53+01:00, Sergey Trofimov wrote:
> I think guix should not embed config generators for user software. 
> The only need I see for such generators is when there are options 
> which should be the same among multiple applications (e.g. color 
> schemes or shared directories). For such usecase guix should 
> provide better text manipulation tools which home owners could use 
> to parameterise configs.

One other case is when it involves other packages,
like native messager for IceCat:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

I would also want to share my experience as a user, that having
to run guix home reconfigure iteratively is not exactly pleasant
due to the high delay.  Home files service suffers the same problem,
and I'm suggesting to allow an option to install the symlink
(e.g. /gnu/store/...-foo -> $HOME/.../foo) to make this convenient.
The user is likely to version control the parent directory anyway,
and the home files config does not include any hash to justify
copying the file to the guix store.