Re: Services can now have a default value

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

Hi Carlo,

Carlo Zancanaro <carlo@zancanaro.id.au> 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
lines.

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
    openssh-service
    (extensions …)
    (configuration
      (port openssh-service-port (default 22))
      (use-pam? openssh-service-use-pam? (default #t))))

and then:

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

Thoughts?

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

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

  https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00608.html

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.

Thanks,
Ludo’.