Intermediate abstraction of system service configuration

[Dale Mellor <no-reply@rdmp.org>]

Hello,

   I am in the process of moving my production machine
to a pure Guix setup, and feeling some pain which I
feel is somewhat unnecessary.

   There are two extremes supported by the Guix system
in configuring services: either a native application
configuration file is given and used verbatim, without
Guix really understanding what is happening, or else a
huge pile of scheme code can be constructed which
resembles the configuration file structurally and is
eventually translated into an actual configuration
file.  The benefit of the former approach is that all
of the configuration options of the application are
available and that the package importer has no work to
do to support the configuration (in writing
translators), but the disadvantage is that this cannot
be introspected or (easily) manipulated by the Guix
system (for example if another application needs to
make modifications so that they can work harmoniously
together).  The advantage of the latter approach is
that the configuration can be more dynamically
constructed, but the disadvantage is that configuration
is restricted to those aspects which the package
importers have gone to (a lot of trouble) to implement,
and for which they have to diligently track changes in
application configuration specification across versions
of the application.

   The two packages which immediately come to mind
which show this extreme dichotomy well are /nginx/ and
/dovecot/; the manual pages for those packages show
reams of configuration clauses available in the Guix
system configuration file (neither of which are
exhaustive, ouch!), and they both also allow a single
native configuration file to be used verbatim.

   There is no middle ground.

   I think that Guix taking the view of a configuration
file as a nested set of string-named blocks containing
lists of string-named, string-valued pairs would be an
intermediate level of abstraction more suited to the
Guix system configuration view of the world.  It has
the advantage that it is introspectible and
programmatically modifiable, yet is flexible enough
that the full configurability of services is available,
and I /think/ it is sufficiently general that it would
cover all cases of application configurations.  It
means that application configuration can be handled
more uniformly across applications by the Guix system,
and importers of applications have a much easier time
coding up the configuration file translator, which
would be relatively trivial in most cases.

   I also believe it would make life easier for people
configuring systems for themselves, especially where
they wish to deviate from 'standard' setups, which is
where I met with most pain.

   So shoot me down  :)

Dale