Re: Are declarative app configs worth it?

[Attila Lendvai <attila@lendvai.name>]

> > - 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.


early detection of the breakage is just one part of the story. then it also needs to be fixed -- before dropping the hammer and abandoing the worksite.

writing and maintaining the tests have a cost, too.


> > - it requires documentation/translation, another hidden cost
> 
> 
> We should only accept configuration procedures that have proper
> documentation, yes.


in this context i recommed:

What is Seen and What is Not Seen
by Bastiat

https://oll.libertyfund.org/page/wswns

or specifically:

"In the sphere of economics an action, a habit, an institution or a law engenders not just one effect but a series of effects. Of these effects only the first is immediate; it is revealed simultaneously with its cause, it is seen. The others merely occur successively, they are not seen;3 we are lucky if we foresee them."

if you demand that e.g. all services accepted into guix have a configuration entry for every possible config field, and that the documentation of these fields are duplicated into the guix codebase... then whatever is included into guix will have a 100% coverage. this is what is seen.

but what about the lost potential? because i can guarantee you that while you'll get 100% coverage, you'll also only get a fraction of the total number services and fields.

which one will yield a better guix experience?

what i'm doing with my own services, and what i also recommend, is to always have an 'extra-arguments or 'extra-fields that allows defining any config value, and serializes it as-is. that way the user can rely on the documentation of the daemon, and blindly apply it while writing the guix config.

and only reify those couple of config fields into scheme code that can provide something useful beyond merely serializing the value as-is.

this way:
 - the guix codebase remains smaller (OAOO principle)
 - updating the app's package in guix is simpler
 - guaranteed not to get out of sync with the app
 - smaller threshold for new contributions
 - which translates to more supported services

i find the free-form module type, as suggested by John Soo above, to be a good idea. so much so that i may even look into writing a prototype and try to use it to replace my two inline shepherd-service instances.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“War is a ritual, a deadly ritual, not the result of aggressive self-assertion, but of self-transcending identification. Without loyalty to tribe, church, flag or ideal, there would be no wars.”
	— Arthur Koestler (1905–1983)