Hey Ludo, On Wed, Apr 19 2017, Ludovic Courtès wrote: > It used to be that we would write ‘-service’ procedures. Then when (gnu > services) was added, each of these procedures would boil down to: > > (define (foo-service #:key (foo foo) (number 42)) > (service foo-service-type > (foo-configuration (foo foo) (number number))))
Indeed, when I look at the postgresql-service procedure, it's doing
exactly this. The mysql-service one doesn't even take keyword arguments,
it just takes a mysql-configuration record and passes it straight
through.
> There are two issues here:
>
> 1. The default values here are redundant with those we also specify in
> <foo-configuration>.
>
> 2. The ‘-service’ procedures are a bit opaque. For things like
> ‘modify-services’, we want to expose the fact that we have service
> objects with an associated <foo-configuration> value, rather than
> hide it inside a procedure.
>
> For these reasons, I’ve been progressively suggesting that we avoid
> ‘-service’ procedures altogether, and deprecate the existing ones.
> There are still many of them though, as you write; we should remove
> them (patches welcome! easy task for a GuixSD newcomer! :-)).
Could we create a mapping from configuration -> service-type? Or somehow
embed the service-type inside the configuration record? (I prefer the
former.) That way we could specify our service list as a list of
configurations without having to doubly-specify the services.
So then instead of
(service foo-service-type
(foo-configuration (foo #f)
(number 42)))
we could have:
(foo-configuration (foo #f)
(number 42))
and have the foo-service-type implicitly looked up when instantiating
the services.
I chose to put the mapping as configuration -> service-type (rather than
the other way around) because I'm aware of the dovecot-service-type
which has two configuration record types: dovecot-configuration and
opaque-dovecot-configuration. This would still restrict things more than
they currently are (where a configuration record type can be shared
between multiple services). I don't know whether that's a problem or
not. We could also leave the option of using the (service ...) form
while inferring it when necessary.
If we had a mapping like this then both of your issues would be solved,
I think: the default values would only have to exist in one place (the
configuration record type), and the configuration records would remain
as the interface for configuration.
> The default value thing in this thread is about making the ‘service’
> form less verbose and closer to what we had with ‘-service’
> procedures.
Yeah, okay. I guess I just saw the change and felt like it doesn't
actually change much. Having a default value saves you a bit of typing,
but only in the case where you don't want to change any configuration
for the service.
The other thing that it would buy you (which is more significant) is the
ability to create services that are required for service extensions, but
which aren't listed in the operating-system's services. I assume we
don't want to do that, though, because that could be
dangerous/surprising.
> Does that clarify things?
Yes, thanks! Are there discussions somewhere that I can read about how
this came together? I don't think I've been on the list long enough to
have seen it myself (or if I have, I can't find them).
Carlo
signature.asc
Description: PGP signature
