Re: Services can now have a default value

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

Hello,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

> On Thu, Apr 20 2017, Ludovic Courtès wrote:
>> 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.
>
> This was my first thought. I couldn't see how to do OO-style inheritance
> with the SRFI-9 API, though. I'm not very experienced with Guile (or
> scheme generally), so I might do some more reading about that.

SRFI-99 supports inheritance, though there’s currently no SRFI-99 module
in Guile proper:

  https://srfi.schemers.org/srfi-99/srfi-99.html

Oh and there’s also R6RS records, SRFI-35… no shortage of record APIs!
:-)

>> 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)))
>
> I also thought about this, but I was concerned about things like
> dovecot-service, where there are two configuration objects. I wouldn't
> want to force us to duplicate code, and create two different service
> types, if we wanted services like that in future.
>
> Although, maybe we would actually rather enforce a "one configuration
> type per service type" rule, for the sake of modifying services? It's
> hard to modify a service if you can't be sure of what the type of the
> configuration will be.

Right, I would prefer one type per service.  I didn’t know dovecot was
different.

> Do you have a preference for what approach to use? If we use a macro to
> generate things then we retain the same flexibility as the current
> approach which removing a bunch of boilerplate, but I'm not sure I have
> the best view of the trade-offs involved.

A ‘define-service-type’ macro or similar could generate either code the
current framework (with <service-type> and <service> and
<foo-configuration>) or for SRFI-99-style records if we later to go that
route.

So I think we should start by designing this macro.

How does that sound?

>> I’m not sure what you mean.  Is it something like what ‘simple-service’
>> does?
>
> I meant something more like what I did with exim-service-type, where I
> extend a service just to ensure its presence, then I had to document
> you have to have a mail-aliases-service-type in order to use exim. With
> a default configuration the mail-aliases-service-type could be
> automatically instantiated if it doesn't exist.

Oh right.

Well I don’t know, perhaps in some cases it might make sense to
automatically instantiate things depended on.  The advantage is that as
a user of the service (exim for instance) you don’t have to be aware of
the services it expects (improves separation of concern).

So you could blissfully write just:

  (cons (service mediagoblin-service-type)
        %base-services)

and behind the scenes it would add an nginx instance, an mcron instance
with a couple of jobs, a rottlog instance, and so on.

WDYT?

Thanks,
Ludo’.