[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#69591] [PATCH] services: shepherd: Support “free-form” services.
From: |
Ludovic Courtès |
Subject: |
[bug#69591] [PATCH] services: shepherd: Support “free-form” services. |
Date: |
Mon, 24 Jun 2024 15:07:28 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Maxim,
(Cc’ing 71739, which is actually the right one. :-))
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
[...]
>> +@item @code{free-form} (default: @code{#f})
>> +When set, this field replaces the @code{start}, @code{stop}, and
>> +@code{actions} fields. It is meant to be used when the service
>> +definition comes from some other source, typically the service
>> +collection provided by the Shepherd proper (@pxref{Service Collection,,,
>> +shepherd, The GNU Shepherd Manual}).
>> +
>> +@cindex REPL service, for shepherd
>> +For example, the snippet below defines a service for the Shepherd's
>> +built-in @acronym{REPL, read-eval-print loop} service (@pxref{REPL
>> +Service,,, shepherd, The GNU Shepherd Manual}):
>> +
>> +@lisp
>> +(shepherd-service
>> + (provision '(repl))
>> + (modules '((shepherd service repl)))
>> + (free-form #~(repl-service)))
>> +@end lisp
[...]
> Hm, if free-form is expected to be a built-in procedure provided by
> Shepherd, should we call it 'built-in' instead of 'free-form' ?
I view it as something more generic: it’s typically, but not just, for
when the service comes from a procedure defined in the Shepherd itself.
Other use case is when as a service author you need more freedom that
what you get with the ‘start’ and ‘stop’ fields, like:
(shepherd-service
;; …
(free-from #~(let ((whatever (spawn-fiber …)))
(service '(foo) #:start …))))
It’s probably going to be a relatively marginal use case, but it’s good
to have that extra level of flexibility.
WDYT?
Thanks!
Ludo’.