Re: Composing service definitions (and maybe fmt)

[ludo@gnu.org (Ludovic Courtès)]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> You may remember my post to the list about how I'm interested in
> service configurations which know about each others' variables.  I wrote
> about why I think this is really important to solving deployment here:
>
>   http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00736.html
>
> If we build procedures which go from procedure inputs -> text and that's
> all that gets passed to the service, do we lose the ability to
> introspect the arguments being used to set up the service?

Not necessarily: <service> object have a ‘parameters’ field to hold the
service’s arguments, and this can always be introspected and
manipulated.

It’s just that there’s a “preferred form” to manipulate these service
parameters.  For instance, a high-level struct is easy to deal with, an
argument list is OK but less convenient, and a file-like object is
pretty bad.

> Would it be possible to have services which themselves set up services?
> Eg, imagine I had something imaginary like:
>
>   (3dprinter-service
>    #:model "lawlsbot-3000"
>    #:fill-pattern "hex")
>
> (Ignore whether or not this is a sane way to configure a 3d printer at
> all at the moment, I'm just making something up)
>
> So, this might actually build the "implied" service of:
>
>   (3dprinter-raw-service
>    "[printconfig]
> model = lawlsbot-3000
> fill-pattern = hex")
>
> ... this way, daring users can provide their own config file if our
> config file builders aren't good enough, but it's still possible to
> have some other service or tool read that the 3dprinter-service has a
> model with lawlsbot-3000, so it can show it in a menu, or something.
>
> Is this possible, or even sane? :)

So you’re suggesting to systematically have a high-level interface as
well as a lower-level interface that gives access to the raw config
file, right?

The problem is that often, the service configuration does not to just
one config file.  Often it also translates into command-line options,
user accounts, etc.  For instance, ‘tor-service’ expects users to pass a
raw config file, but it also needs to create a user account whose name
is given in that config file, so it needs to control that part of the
config file.

That being said, it’s always possible to extend ‘etc-service-type’ and
give it raw config files.

Not offering any concrete solution but… does that make sense?  :-)

Thanks,
Ludo’.