| Message ID | 20210801210254.6119-1-brice@waegenei.re |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#49812] services: In MODIFY-SERVICES macro allow specifying a service by its name. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
Hi, Brice Waegeneire <brice@waegenei.re> skribis: > This is specially useful with any services singleton created with > 'simple-service' such as 'set-xorg-configuration'. Could you show an example? Services created by ‘simple-service’ & co. are effectively anonymous; it’s a bit like a lambda. > * doc/guix.texi (Service Reference)[modify-services]: Document support > for specifying service by its name. > * gnu/services.scm (modify-services): Support specifying a service by > its name in addition to its type. [...] > +++ b/gnu/services.scm > @@ -303,8 +303,9 @@ singleton service type NAME, of which the returned service is an instance." > (%modify-service svc clauses ...))) > ((_ service) > service) > - ((_ svc (kind param => exp ...) clauses ...) > - (if (eq? (service-kind svc) kind) > + ((_ svc (kind-or-name param => exp ...) clauses ...) > + (if (or (eq? (service-kind svc) kind-or-name) ;kind > + (eq? (service-type-name (service-kind svc)) kind-or-name)) ;name As a general design pattern in Guix, “names” (symbols) are here for UI and/or debugging purposes; they should not be used elsewhere because, by definition, names are ambiguous. Conversely, object references are unambiguous and non-forgeable, so I prefer interfaces that avoid “names” entirely. I hope that makes sense! Ludo’.
diff --git a/doc/guix.texi b/doc/guix.texi index 2298d512a1..3b50976358 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -34319,20 +34319,20 @@ standard list combinators such as @code{map} and @code{fold} to do that common pattern. @deffn {Scheme Syntax} modify-services @var{services} @ - (@var{type} @var{variable} => @var{body}) @dots{} + (@var{type-or-name} @var{variable} => @var{body}) @dots{} Modify the services listed in @var{services} according to the given clauses. Each clause has the form: @example -(@var{type} @var{variable} => @var{body}) +(@var{type-or-name} @var{variable} => @var{body}) @end example -where @var{type} is a service type---e.g., -@code{guix-service-type}---and @var{variable} is an identifier that is -bound within the @var{body} to the service parameters---e.g., a -@code{guix-configuration} instance---of the original service of that -@var{type}. +where @var{type-or-name} is a service type or name---e.g., +@code{guix-service-type} or @code{'guix}---and @var{variable} is an +identifier that is bound within the @var{body} to the service +parameters---e.g., a @code{guix-configuration} instance---of the +original service of that type. The @var{body} should evaluate to the new service parameters, which will be used to configure the new service. This new service will replace the diff --git a/gnu/services.scm b/gnu/services.scm index 2a8114a219..736ad2e4b9 100644 --- a/gnu/services.scm +++ b/gnu/services.scm @@ -303,8 +303,9 @@ singleton service type NAME, of which the returned service is an instance." (%modify-service svc clauses ...))) ((_ service) service) - ((_ svc (kind param => exp ...) clauses ...) - (if (eq? (service-kind svc) kind) + ((_ svc (kind-or-name param => exp ...) clauses ...) + (if (or (eq? (service-kind svc) kind-or-name) ;kind + (eq? (service-type-name (service-kind svc)) kind-or-name)) ;name (let ((param (service-value svc))) (service (service-kind svc) (begin exp ...)))