[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Services can now have a default value

From: Ludovic Courtès
Subject: Re: Services can now have a default value
Date: Wed, 19 Apr 2017 23:20:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)


Carlo Zancanaro <address@hidden> skribis:

> I have a question related to this, but about a broader issue.
> On Sat, Apr 15 2017, Ludovic Courtès wrote:
>>   (service openssh-service-type)
> Is this supposed to be the preferred way to add a service to your
> operating system? Or, put another way, as a service writer: should I
> consider a *-service-type to be sufficient to complete the work of
> creating a service?


> Looking at various services that we have defined at the moment
> (according to what is documented), most services have a procedure (ie.
> *-service), and maybe also a *-service-type. For example, in "Database
> Services" we have postgresql-service and mysql-service, with no
> corresponding *-service-type. But then we have redis-service-type
> without a *-service to go with it.
> I wonder if we would be better off creating *-service procedures for
> each *-service-type and documenting them as the canonical way to create
> services. That way we could handle things like default arguments through
> the usual scheme mechanisms, rather than our own special case.

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

There are two issues here:

  1. The default values here are redundant with those we also specify in

  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! :-)).

The default value thing in this thread is about making the ‘service’
form less verbose and closer to what we had with ‘-service’ procedures.

Clearly there’s a parallel between procedures with keyword parameters
and services/configurations records with default field values.  The key
here is that we want first-class objects that we can inspect and derive
from when customizing a system.

Does that clarify things?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]