| Message ID | 871r8j4rer.fsf@trop.in |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#49288] gnu: services: Export provenance-entry and sexp->channel | 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! Andrew Tropin <andrew@trop.in> skribis: > These functions are need for Guix Home. > --- > For now functions are copy pasted, but it seems better to reuse > existing functions. > https://git.sr.ht/~abcdw/rde/tree/057888b2604b05d555fd1b67f3d356644f9a134d/gnu/home-services.scm#L418 > > gnu/services.scm | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gnu/services.scm b/gnu/services.scm > index 8d413e198e..53b358c63b 100644 > --- a/gnu/services.scm > +++ b/gnu/services.scm > @@ -91,6 +91,9 @@ > ambiguous-target-service-error-service > ambiguous-target-service-error-target-type > > + provenance-entry > + sexp->channel This ‘sexp->channel’ exists “for historical reasons”. Could you use (@ (guix channels) sexp->channel) instead, together with ‘channel-instance->sexp’? Actually, could you define it like so: --8<---------------cut here---------------start------------->8--- (define home-provenance-service-type (service-type (inherit provenance-service-type) (extensions (list (service-extension home-service-type (service-extension-compute (first (service-extensions provenance-service-type)))))) (default-value #f))) --8<---------------cut here---------------end--------------->8--- More generally, perhaps you could have a procedure that takes a service type and “rewires” it so that it extends ‘home-service-type’ instead of ‘etc-service-type’, say. Does that make sense? Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi! > > Andrew Tropin <andrew@trop.in> skribis: > >> These functions are need for Guix Home. >> --- >> For now functions are copy pasted, but it seems better to reuse >> existing functions. >> https://git.sr.ht/~abcdw/rde/tree/057888b2604b05d555fd1b67f3d356644f9a134d/gnu/home-services.scm#L418 >> >> gnu/services.scm | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/gnu/services.scm b/gnu/services.scm >> index 8d413e198e..53b358c63b 100644 >> --- a/gnu/services.scm >> +++ b/gnu/services.scm >> @@ -91,6 +91,9 @@ >> ambiguous-target-service-error-service >> ambiguous-target-service-error-target-type >> >> + provenance-entry >> + sexp->channel > > This ‘sexp->channel’ exists “for historical reasons”. Could you use > (@ (guix channels) sexp->channel) instead, together with > ‘channel-instance->sexp’? Sure!) > Actually, could you define it like so: > > --8<---------------cut here---------------start------------->8--- > (define home-provenance-service-type > (service-type > (inherit provenance-service-type) > (extensions > (list (service-extension > home-service-type > (service-extension-compute > (first (service-extensions provenance-service-type)))))) > (default-value #f))) > --8<---------------cut here---------------end--------------->8--- Looks good to me. > More generally, perhaps you could have a procedure that takes a service > type and “rewires” it so that it extends ‘home-service-type’ instead of > ‘etc-service-type’, say. Does that make sense? Thank you for the idea, it can be useful, I'll consider it.
diff --git a/gnu/services.scm b/gnu/services.scm index 8d413e198e..53b358c63b 100644 --- a/gnu/services.scm +++ b/gnu/services.scm @@ -91,6 +91,9 @@ ambiguous-target-service-error-service ambiguous-target-service-error-target-type + provenance-entry + sexp->channel + system-service-type provenance-service-type sexp->system-provenance