Hi Xinglu, Xinglu Chen <pub...@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