Re: Are declarative app configs worth it?

[Attila Lendvai]

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