Re: Best practices for writing services

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Xinglu,

Xinglu Chen <public@yoctocell.xyz> writes:

> Hi,
>
> On Tue, Apr 20 2021, Maxim Cournoyer wrote:
>
>> That's a very good question, which I asked myself recently when
>> attempting to write my first non-trivial service for Guix
>> (jami-daemon-service-type).  I'd say 'define-configuration' is
>> technically superior because of the automatic type checking it provides.
>> It's also neat to be able to define the doc at one place and
>> auto-generate it (although that's still manual for now).
>
> You mean that one has to manually evaluate the ‘generate-documentation’
> sexp and paste the output of it in the manual?  I thought it would
> automatically update the manual when running ‘make’. ;)

Yes, that's my current understanding of how things are.  It could be
changed, for sure.

>> It has definitely been collecting some dust compared to the simpler
>> approach using 'define-record-type*' directly, and the doc output it
>> can generate doesn't match what is currently the norm in the manual,
>> so it'd need a bit of a refresh.
>
> Yeah, I noticed that some sections in the manual looked a bit different
> than the rest.
>
> One thing that I find a little annoying is that you have to specify a
> default value for the fields.  This doesn’t make much sense in some
> cases, e.g. there is no good default value for ‘user.name = NAME’ in the
> Git config, the user should have to specify that themselves.

There's a 'define-maybe' that can be used to declare a field that can
take more than one type, e.g.:

(define-maybe string)

Will generate a definition like so:

--8<---------------cut here---------------start------------->8---
(define (maybe-string? val)
               (or (eq? val 'disabled) (string? val)))
--8<---------------cut here---------------end--------------->8---

Which the validator of define-configuration will use if you specify a
field with the type 'maybe-string'.

'disabled is a bit semantically broken in some cases ('unspecified'
could be nicer), but it does the job.

> Another thing is that I don’t always want to “serialize-” the value for a
> field, so I sometimes end up defining a bunch of dummy serializers that
> just return an empty string.

Good point!  I've tried addressing that, without success so far [0].

Maxim

[0]  https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00184.html