[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: Thu, 20 Apr 2017 10:42:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hi Carlo,

Carlo Zancanaro <address@hidden> skribis:

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

There must be some sort of a mapping between service types and
configuration types, indeed, but I’m not sure how to achieve it.

One solution would be to have all the <foo-configuration> records
inherit (in the OO sense) from <service>, or something along these

Or we could make <service-type> “struct vtables” and then make
<foo-configuration> instances of those vtables (info "(guile) Vtables").
I’d rather avoid using those interfaces, though (currently the only
record API we use is SRFI-9.)

Or we could have a ‘define-service’ macro that defines both the
<service-type> and the <foo-configuration>, and defines a ‘foo-service’
macro equivalent to (service foo-service-type (foo-configuration …)).

  (define-service-type openssh-service-type
    (extensions …)
      (port openssh-service-port (default 22))
      (use-pam? openssh-service-use-pam? (default #t))))

and then:

     ;; …
     (services (cons (openssh-service (port 2222)) %base-services)))


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

I’m not sure what you mean.  Is it something like what ‘simple-service’

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

It all started with the new service API, which introduced service types
and service objects:

The specific issue we’re discussing hasn’t received much attention
though, but it’s been discussed a few times as people were adding new
service definitions.


reply via email to

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