* [bug#65119] [PATCH 1/8] services: dicod: Remove Shepherd < 0.9.0 compatibility layer.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 2/8] services: dicod: Pre-build the GCIDE index Ludovic Courtès
` (7 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/services/dict.scm (dicod-shepherd-service): Use
'make-inetd-constructor' and 'make-inetd-destructor' unconditionally.
---
gnu/services/dict.scm | 31 ++++++++++++-------------------
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/gnu/services/dict.scm b/gnu/services/dict.scm
index 23e1d36364..7d48953ef1 100644
--- a/gnu/services/dict.scm
+++ b/gnu/services/dict.scm
@@ -167,25 +167,18 @@ (define (dicod-shepherd-service config)
(provision '(dicod))
(requirement '(user-processes))
(documentation "Run the dicod daemon.")
- (start #~(if (defined? 'make-inetd-constructor)
- (make-inetd-constructor
- (list #$dicod "--inetd" "--foreground"
- (string-append "--config=" #$dicod.conf))
- (map (lambda (interface)
- (endpoint
- (addrinfo:addr
- (car (getaddrinfo interface "dict")))))
- '#$interfaces)
- #:requirements '#$requirement
- #:user "dicod" #:group "dicod"
- #:service-name-stem "dicod")
- (make-forkexec-constructor
- (list #$dicod "--foreground"
- (string-append "--config=" #$dicod.conf))
- #:user "dicod" #:group "dicod")))
- (stop #~(if (defined? 'make-inetd-destructor)
- (make-inetd-destructor)
- (make-kill-destructor)))
+ (start #~(make-inetd-constructor
+ (list #$dicod "--inetd" "--foreground"
+ (string-append "--config=" #$dicod.conf))
+ (map (lambda (interface)
+ (endpoint
+ (addrinfo:addr
+ (car (getaddrinfo interface "dict")))))
+ '#$interfaces)
+ #:requirements '#$requirement
+ #:user "dicod" #:group "dicod"
+ #:service-name-stem "dicod"))
+ (stop #~(make-inetd-destructor))
(actions (list (shepherd-configuration-action dicod.conf)))))))
(define dicod-service-type
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 2/8] services: dicod: Pre-build the GCIDE index.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 1/8] services: dicod: Remove Shepherd < 0.9.0 compatibility layer Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 3/8] services: syncthing: Use 'match-record' Ludovic Courtès
` (6 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/services/dict.scm (%dicod-gcide-index): New variable.
(%dicod-database:gcide): Use it.
(%dicod-activation): Remove.
(dicod-shepherd-service): Remove reference to /var/run/dicod.
(dicod-service-type): Remove ACTIVATION-SERVICE-TYPE extension.
---
gnu/services/dict.scm | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/gnu/services/dict.scm b/gnu/services/dict.scm
index 7d48953ef1..f542921302 100644
--- a/gnu/services/dict.scm
+++ b/gnu/services/dict.scm
@@ -73,12 +73,24 @@ (define-record-type* <dicod-database>
(complex? dicod-database-complex? (default #f))
(options dicod-database-options (default '())))
+(define %dicod-gcide-index
+ ;; The GCIDE pre-built index. The Dico 'gcide' module can build it lazily;
+ ;; do it upfront so there's no need for a writable directory at run-time.
+ (computed-file "dicod-gcide-index"
+ (with-imported-modules '((guix build utils))
+ #~(begin
+ (use-modules (guix build utils))
+ (mkdir #$output)
+ (invoke #+(file-append dico "/libexec/idxgcide")
+ #+(file-append gcide "/share/gcide")
+ #$output)))))
+
(define %dicod-database:gcide
(dicod-database
(name "gcide")
(handler "gcide")
(options (list #~(string-append "dbdir=" #$gcide "/share/gcide")
- "idxdir=/var/run/dicod"))))
+ #~(string-append "idxdir=" #$%dicod-gcide-index)))))
(define %dicod-accounts
(list (user-group
@@ -137,14 +149,6 @@ (define (dicod-configuration-file config)
(apply mixed-text-file "dicod.conf" (configuration->text config)))
-(define %dicod-activation
- #~(begin
- (use-modules (guix build utils))
- (let ((user (getpwnam "dicod"))
- (rundir "/var/run/dicod"))
- (mkdir-p rundir)
- (chown rundir (passwd:uid user) (passwd:gid user)))))
-
(define (dicod-shepherd-service config)
(let* ((dicod.conf (dicod-configuration-file config))
(interfaces (dicod-configuration-interfaces config))
@@ -153,10 +157,6 @@ (define (dicod-shepherd-service config)
"/bin/dicod")
#:name "dicod"
#:mappings (list (file-system-mapping
- (source "/var/run/dicod")
- (target source)
- (writable? #t))
- (file-system-mapping
(source "/dev/log")
(target source))
(file-system-mapping
@@ -187,8 +187,6 @@ (define dicod-service-type
(extensions
(list (service-extension account-service-type
(const %dicod-accounts))
- (service-extension activation-service-type
- (const %dicod-activation))
(service-extension shepherd-root-service-type
dicod-shepherd-service)))
(default-value (dicod-configuration))
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 3/8] services: syncthing: Use 'match-record'.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 1/8] services: dicod: Remove Shepherd < 0.9.0 compatibility layer Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 2/8] services: dicod: Pre-build the GCIDE index Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 4/8] services: Define 'for-home' Ludovic Courtès
` (5 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/services/syncthing.scm (syncthing-shepherd-service): Use
'match-record-lambda' instead of 'match-lambda'.
---
gnu/services/syncthing.scm | 52 +++++++++++++++++++-------------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/gnu/services/syncthing.scm b/gnu/services/syncthing.scm
index 7c3d5b027d..8f94aef088 100644
--- a/gnu/services/syncthing.scm
+++ b/gnu/services/syncthing.scm
@@ -51,32 +51,32 @@ (define-record-type* <syncthing-configuration>
(default #f)))
(define syncthing-shepherd-service
- (match-lambda
- (($ <syncthing-configuration> syncthing arguments logflags user group home)
- (list
- (shepherd-service
- (provision (list (string->symbol (string-append "syncthing-" user))))
- (documentation "Run syncthing.")
- (requirement '(loopback))
- (start #~(make-forkexec-constructor
- (append (list (string-append #$syncthing "/bin/syncthing")
- "-no-browser"
- "-no-restart"
- (string-append "-logflags=" (number->string #$logflags)))
- '#$arguments)
- #:user #$user
- #:group #$group
- #:environment-variables
- (append (list (string-append "HOME=" (or #$home (passwd:dir (getpw #$user))))
- "SSL_CERT_DIR=/etc/ssl/certs"
- "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt")
- (remove (lambda (str)
- (or (string-prefix? "HOME=" str)
- (string-prefix? "SSL_CERT_DIR=" str)
- (string-prefix? "SSL_CERT_FILE=" str)))
- (environ)))))
- (respawn? #f)
- (stop #~(make-kill-destructor)))))))
+ (match-record-lambda <syncthing-configuration>
+ (syncthing arguments logflags user group home)
+ (list
+ (shepherd-service
+ (provision (list (string->symbol (string-append "syncthing-" user))))
+ (documentation "Run syncthing.")
+ (requirement '(loopback))
+ (start #~(make-forkexec-constructor
+ (append (list (string-append #$syncthing "/bin/syncthing")
+ "-no-browser"
+ "-no-restart"
+ (string-append "-logflags=" (number->string #$logflags)))
+ '#$arguments)
+ #:user #$user
+ #:group #$group
+ #:environment-variables
+ (append (list (string-append "HOME=" (or #$home (passwd:dir (getpw #$user))))
+ "SSL_CERT_DIR=/etc/ssl/certs"
+ "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt")
+ (remove (lambda (str)
+ (or (string-prefix? "HOME=" str)
+ (string-prefix? "SSL_CERT_DIR=" str)
+ (string-prefix? "SSL_CERT_FILE=" str)))
+ (environ)))))
+ (respawn? #f)
+ (stop #~(make-kill-destructor))))))
(define syncthing-service-type
(service-type (name 'syncthing)
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 4/8] services: Define 'for-home'.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
` (2 preceding siblings ...)
2023-08-06 21:07 ` [bug#65119] [PATCH 3/8] services: syncthing: Use 'match-record' Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 5/8] home: services: Support mapping of System services to Home services Ludovic Courtès
` (4 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/services.scm (remove-service-extensions): New procedure.
(for-home?): New syntax parameter.
(for-home): New macro.
---
gnu/services.scm | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/gnu/services.scm b/gnu/services.scm
index 109e050a23..eb9258977e 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2015-2022 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2015-2023 Ludovic Courtès <ludo@gnu.org>
;;; Copyright © 2016 Chris Marusich <cmmarusich@gmail.com>
;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
;;; Copyright © 2020, 2021 Ricardo Wurmus <rekado@elephly.net>
@@ -86,6 +86,10 @@ (define-module (gnu services)
instantiate-missing-services
fold-services
+ remove-service-extensions
+ for-home
+ for-home?
+
service-error?
missing-value-service-error?
missing-value-service-error-type
@@ -1225,4 +1229,23 @@ (define* (fold-services services
(G_ "more than one target service of type '~a'")
(service-type-name target-type)))))))))
+(define (remove-service-extensions type lst)
+ "Return TYPE, a service type, without any of the service extensions
+targeting one of the types in LST."
+ (service-type
+ (inherit type)
+ (extensions (remove (lambda (extension)
+ (memq (service-extension-target extension) lst))
+ (service-type-extensions type)))))
+
+(define-syntax-parameter for-home?
+ ;; Whether the configuration being defined is for a Home service.
+ (identifier-syntax #f))
+
+(define-syntax-rule (for-home exp ...)
+ "Mark EXP, which typically defines a service configuration, as targeting a
+Home service rather than a System service."
+ (syntax-parameterize ((for-home? (identifier-syntax #t)))
+ exp ...))
+
;;; services.scm ends here.
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 5/8] home: services: Support mapping of System services to Home services.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
` (3 preceding siblings ...)
2023-08-06 21:07 ` [bug#65119] [PATCH 4/8] services: Define 'for-home' Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 6/8] home: services: mcron: Define as a mapping of the system service Ludovic Courtès
` (3 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/home/services.scm (service-type-mapping)
(system->home-service-type): New procedures.
(define-service-type-mapping, define-service-type-mappings): New macros.
(%system/home-service-type-mapping): New variable.
<top level>: Use 'define-service-type-mappings'.
* gnu/home/services/shepherd.scm <top level>: Likewise.
---
gnu/home/services.scm | 69 +++++++++++++++++++++++++++++++++-
gnu/home/services/shepherd.scm | 4 +-
2 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/gnu/home/services.scm b/gnu/home/services.scm
index 042eba4780..8d53f2f4d3 100644
--- a/gnu/home/services.scm
+++ b/gnu/home/services.scm
@@ -33,6 +33,7 @@ (define-module (gnu home services)
#:use-module (guix diagnostics)
#:use-module (guix i18n)
#:use-module (guix modules)
+ #:use-module (guix memoization)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-9)
#:use-module (ice-9 match)
@@ -63,11 +64,16 @@ (define-module (gnu home services)
lookup-home-service-types
home-provenance
+ define-service-type-mapping
+ system->home-service-type
+
%initialize-gettext)
#:re-export (service
service-type
- service-extension))
+ service-extension
+ for-home
+ for-home?))
;;; Comment:
;;;
@@ -513,6 +519,67 @@ (define home-activation-service-type
reconfiguration or generation switching. This service can be extended
with one gexp, but many times, and all gexps must be idempotent.")))
+\f
+;;;
+;;; Service type graph rewriting.
+;;;
+
+(define (service-type-mapping proc)
+ "Return a procedure that applies PROC to map a service type graph to another
+one."
+ (define (rewrite extension)
+ (match (proc (service-extension-target extension))
+ (#f #f)
+ (target
+ (service-extension target
+ (service-extension-compute extension)))))
+
+ (define replace
+ (mlambdaq (type)
+ (service-type
+ (inherit type)
+ (name (symbol-append 'home- (service-type-name type)))
+ (location (service-type-location type))
+ (extensions (filter-map rewrite (service-type-extensions type))))))
+
+ replace)
+
+(define %system/home-service-type-mapping
+ ;; Mapping of System to Home services.
+ (make-hash-table))
+
+(define system->home-service-type
+ ;; Map the given System service type to the corresponding Home service type.
+ (let ()
+ (define (replace type)
+ (define replacement
+ (hashq-ref %system/home-service-type-mapping type
+ *unspecified*))
+
+ (if (eq? replacement *unspecified*)
+ type
+ replacement))
+
+ (service-type-mapping replace)))
+
+(define-syntax define-service-type-mapping
+ (syntax-rules (=>)
+ ((_ system-type => home-type)
+ (hashq-set! %system/home-service-type-mapping
+ system-type home-type))))
+
+(define-syntax define-service-type-mappings
+ (syntax-rules (=>)
+ ((_ (system-type => home-type) ...)
+ (begin
+ (define-service-type-mapping system-type => home-type)
+ ...))))
+
+(define-service-type-mappings
+ (system-service-type => home-service-type)
+ (activation-service-type => home-activation-service-type)
+ (profile-service-type => home-profile-service-type))
+
\f
;;;
;;; On-change.
diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm
index 5585ef61b2..bd068c37fc 100644
--- a/gnu/home/services/shepherd.scm
+++ b/gnu/home/services/shepherd.scm
@@ -141,7 +141,7 @@ (define (ensure-shepherd-gexp config)
(define (shepherd-xdg-configuration-files config)
`(("shepherd/init.scm" ,(home-shepherd-configuration-file config))))
-(define-public home-shepherd-service-type
+(define home-shepherd-service-type
(service-type (name 'home-shepherd)
(extensions
(list (service-extension
@@ -168,4 +168,6 @@ (define-public home-shepherd-service-type
(default-value (home-shepherd-configuration))
(description "Configure and install userland Shepherd.")))
+(define-service-type-mapping
+ shepherd-root-service-type => home-shepherd-service-type)
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 6/8] home: services: mcron: Define as a mapping of the system service.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
` (4 preceding siblings ...)
2023-08-06 21:07 ` [bug#65119] [PATCH 5/8] home: services: Support mapping of System services to Home services Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-21 15:50 ` Andrew Tropin
2023-08-06 21:07 ` [bug#65119] [PATCH 7/8] home: services: Add dicod Ludovic Courtès
` (2 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/services/mcron.scm (list-of-gexps?): Remove.
(<mcron-configuration>): Rewrite using 'define-record-type*'.
[home-service?]: New field.
[log-file]: Make thunked and changed default value.
(mcron-shepherd-services): Honor 'home-service?' and remove use of
'maybe-value-set?'.
(mcron-service-type): Inherit 'home-service?' from CONFIG.
(generate-doc): Remove.
* gnu/home/services/mcron.scm (list-of-gexp?)
(<home-mcron-configuration>, job-files, shepherd-schedule-action)
(home-mcron-shepherd-services, home-mcron-profile)
(home-mcron-extend, generate-doc): Remove.
(home-mcron-configuration): Turn into a macro.
(home-mcron-service-type): Define in terms of
'system->home-service-type'.
<top level>: Add service type mapping.
---
gnu/home/services/mcron.scm | 96 ++++---------------------------------
gnu/services/mcron.scm | 80 ++++++++++++++-----------------
2 files changed, 45 insertions(+), 131 deletions(-)
diff --git a/gnu/home/services/mcron.scm b/gnu/home/services/mcron.scm
index f51edd6634..23be44ba07 100644
--- a/gnu/home/services/mcron.scm
+++ b/gnu/home/services/mcron.scm
@@ -2,6 +2,7 @@
;;; Copyright © 2021, 2023 Andrew Tropin <andrew@trop.in>
;;; Copyright © 2021 Xinglu Chen <public@yoctocell.xyz>
;;; Copyright © 2022 Maxim Cournoyer <maxim.cournoyer@gmail.com>
+;;; Copyright © 2023 Ludovic Courtès <ludo@gnu.org>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -19,16 +20,9 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (gnu home services mcron)
- #:use-module (gnu packages guile-xyz)
#:use-module (gnu home services)
- #:use-module (gnu services configuration)
- #:use-module (gnu services shepherd)
#:use-module (gnu home services shepherd)
- #:use-module (guix records)
- #:use-module (guix gexp)
- #:use-module (srfi srfi-1)
- #:use-module (ice-9 match)
-
+ #:use-module (gnu services mcron) ;for the service mapping
#:export (home-mcron-configuration
home-mcron-service-type))
@@ -55,86 +49,16 @@ (define-module (gnu home services mcron)
;;
;;; Code:
-(define list-of-gexps?
- (list-of gexp?))
-
-(define-configuration/no-serialization home-mcron-configuration
- (mcron (file-like mcron) "The mcron package to use.")
- (jobs
- (list-of-gexps '())
- "This is a list of gexps (@pxref{G-Expressions}), where each gexp
-corresponds to an mcron job specification (@pxref{Syntax, mcron job
-specifications,, mcron, GNU@tie{}mcron}).")
- (log? (boolean #t) "Log messages to standard output.")
- (log-format
- (string "~1@*~a ~a: ~a~%")
- "@code{(ice-9 format)} format string for log messages. The default value
-produces messages like \"@samp{@var{pid} @var{name}:
-@var{message}\"} (@pxref{Invoking mcron, Invoking,, mcron, GNU@tie{}mcron}).
-Each message is also prefixed by a timestamp by GNU Shepherd."))
-
-(define job-files (@@ (gnu services mcron) job-files))
-(define shepherd-schedule-action
- (@@ (gnu services mcron) shepherd-schedule-action))
-
-(define (home-mcron-shepherd-services config)
- (match-record config <home-mcron-configuration>
- (mcron jobs log? log-format)
- (if (null? jobs)
- '() ;no jobs to run
- (let ((files (job-files mcron jobs)))
- (list (shepherd-service
- (documentation "User cron jobs.")
- (provision '(mcron))
- (modules `((srfi srfi-1)
- (srfi srfi-26)
- (ice-9 popen) ;for the 'schedule' action
- (ice-9 rdelim)
- (ice-9 match)
- ,@%default-modules))
- (start #~(make-forkexec-constructor
- (list (string-append #$mcron "/bin/mcron")
- #$@(if log?
- #~("--log" "--log-format" #$log-format)
- #~())
- #$@files)
- #:log-file (string-append
- (or (getenv "XDG_STATE_HOME")
- (format #f "~a/.local/state"
- (getenv "HOME")))
- "/log/mcron.log")))
- (stop #~(make-kill-destructor))
- (actions
- (list (shepherd-schedule-action mcron files)))))))))
-
-(define home-mcron-profile (compose list home-mcron-configuration-mcron))
-
-(define (home-mcron-extend config jobs)
- (home-mcron-configuration
- (inherit config)
- (jobs (append (home-mcron-configuration-jobs config)
- jobs))))
+(define-syntax-rule (home-mcron-configuration fields ...)
+ ;; Macro provided for backward compatibility.
+ (for-home (mcron-configuration fields ...)))
(define home-mcron-service-type
- (service-type (name 'home-mcron)
- (extensions
- (list (service-extension
- home-shepherd-service-type
- home-mcron-shepherd-services)
- (service-extension
- home-profile-service-type
- home-mcron-profile)))
- (compose concatenate)
- (extend home-mcron-extend)
- (default-value (home-mcron-configuration))
- (description
- "Install and configure the GNU mcron cron job manager.")))
+ (service-type
+ (inherit (system->home-service-type mcron-service-type))
+ (default-value (for-home (mcron-configuration)))))
-\f
-;;;
-;;; Generate documentation.
-;;;
-(define (generate-doc)
- (configuration->documentation 'home-mcron-configuration))
+(define-service-type-mapping
+ mcron-service-type => home-mcron-service-type)
;;; mcron.scm ends here
diff --git a/gnu/services/mcron.scm b/gnu/services/mcron.scm
index 2ef5980e09..db8b539ff5 100644
--- a/gnu/services/mcron.scm
+++ b/gnu/services/mcron.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2016-2020, 2023 Ludovic Courtès <ludo@gnu.org>
;;; Copyright © 2022 Maxim Cournoyer <maxim.cournoyer@gmail.com>
;;; Copyright © 2023 Bruno Victal <mirai@makinata.eu>
;;;
@@ -20,10 +20,8 @@
(define-module (gnu services mcron)
#:use-module (gnu services)
- #:use-module (gnu services configuration)
#:use-module (gnu services shepherd)
#:use-module (gnu packages guile-xyz)
- #:use-module (guix deprecation)
#:use-module (guix records)
#:use-module (guix gexp)
#:use-module (srfi srfi-1)
@@ -37,6 +35,7 @@ (define-module (gnu services mcron)
mcron-configuration-log-file
mcron-configuration-log-format
mcron-configuration-date-format
+ mcron-configuration-home-service?
mcron-service-type))
@@ -55,40 +54,34 @@ (define-module (gnu services mcron)
;;;
;;; Code:
-(define list-of-gexps?
- (list-of gexp?))
+;; Configuration of mcron.
+;; XXX: 'define-configuration' cannot be used here due to the need for
+;; 'thunked' and 'innate' fields as well as 'this-mcron-configuration'.
+(define-record-type* <mcron-configuration> mcron-configuration
+ make-mcron-configuration
+ mcron-configuration?
+ this-mcron-configuration
-(define-maybe/no-serialization string)
+ (mcron mcron-configuration-mcron ;file-like
+ (default mcron))
+ (jobs mcron-configuration-jobs ;list of gexps
+ (default '()))
+ (log? mcron-configuration-log? ;Boolean
+ (default #t))
+ (log-file mcron-configuration-log-file ;string | gexp
+ (thunked)
+ (default
+ (if (mcron-configuration-home-service?
+ this-mcron-configuration)
+ #~(string-append %user-log-dir "/mcron.log")
+ "/var/log/mcron.log")))
+ (log-format mcron-configuration-log-format ;string
+ (default "~1@*~a ~a: ~a~%"))
+ (date-format mcron-configuration-date-format ;string | #f
+ (default #f))
-(define-configuration/no-serialization mcron-configuration
- (mcron
- (file-like mcron)
- "The mcron package to use.")
-
- (jobs
- (list-of-gexps '())
- "This is a list of gexps (@pxref{G-Expressions}), where each gexp
-corresponds to an mcron job specification (@pxref{Syntax, mcron job
-specifications,, mcron, GNU@tie{}mcron}).")
-
- (log?
- (boolean #t)
- "Log messages to standard output.")
-
- (log-file
- (string "/var/log/mcron.log")
- "Log file location.")
-
- (log-format
- (string "~1@*~a ~a: ~a~%")
- "@code{(ice-9 format)} format string for log messages. The default value
-produces messages like @samp{@var{pid} @var{name}: @var{message}}
-(@pxref{Invoking mcron, Invoking,, mcron, GNU@tie{}mcron}).
-Each message is also prefixed by a timestamp by GNU Shepherd.")
-
- (date-format
- maybe-string
- "@code{(srfi srfi-19)} format string for date."))
+ (home-service? mcron-configuration-home-service?
+ (default for-home?) (innate)))
(define (job-files mcron jobs)
"Return a list of file-like object for JOBS, a list of gexps."
@@ -158,13 +151,15 @@ (define (shepherd-schedule-action mcron files)
(define (mcron-shepherd-services config)
(match-record config <mcron-configuration>
- (mcron jobs log? log-file log-format date-format)
+ (mcron jobs log? log-file log-format date-format home-service?)
(if (eq? jobs '())
'() ;nothing to do
(let ((files (job-files mcron jobs)))
(list (shepherd-service
(provision '(mcron))
- (requirement '(user-processes))
+ (requirement (if home-service?
+ '()
+ '(user-processes)))
(modules `((srfi srfi-1)
(srfi srfi-26)
(ice-9 popen) ;for the 'schedule' action
@@ -175,7 +170,7 @@ (define (mcron-shepherd-services config)
(list #$(file-append mcron "/bin/mcron")
#$@(if log?
`("--log" "--log-format" ,log-format
- ,@(if (maybe-value-set? date-format)
+ ,@(if date-format
(list "--date-format"
date-format)
'()))
@@ -209,15 +204,10 @@ (define mcron-service-type
(extend (lambda (config jobs)
(mcron-configuration
(inherit config)
+ (home-service?
+ (mcron-configuration-home-service? config))
(jobs (append (mcron-configuration-jobs config)
jobs)))))
(default-value (mcron-configuration)))) ;empty job list
-\f
-;;;
-;;; Generate documentation.
-;;;
-(define (generate-doc)
- (configuration->documentation 'mcron-configuration))
-
;;; mcron.scm ends here
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 6/8] home: services: mcron: Define as a mapping of the system service.
2023-08-06 21:07 ` [bug#65119] [PATCH 6/8] home: services: mcron: Define as a mapping of the system service Ludovic Courtès
@ 2023-08-21 15:50 ` Andrew Tropin
0 siblings, 0 replies; 25+ messages in thread
From: Andrew Tropin @ 2023-08-21 15:50 UTC (permalink / raw)
To: Ludovic Courtès, 65119
[-- Attachment #1: Type: text/plain, Size: 12561 bytes --]
On 2023-08-06 23:07, Ludovic Courtès wrote:
> * gnu/services/mcron.scm (list-of-gexps?): Remove.
> (<mcron-configuration>): Rewrite using 'define-record-type*'.
> [home-service?]: New field.
> [log-file]: Make thunked and changed default value.
> (mcron-shepherd-services): Honor 'home-service?' and remove use of
> 'maybe-value-set?'.
> (mcron-service-type): Inherit 'home-service?' from CONFIG.
> (generate-doc): Remove.
> * gnu/home/services/mcron.scm (list-of-gexp?)
> (<home-mcron-configuration>, job-files, shepherd-schedule-action)
> (home-mcron-shepherd-services, home-mcron-profile)
> (home-mcron-extend, generate-doc): Remove.
> (home-mcron-configuration): Turn into a macro.
> (home-mcron-service-type): Define in terms of
> 'system->home-service-type'.
> <top level>: Add service type mapping.
> ---
> gnu/home/services/mcron.scm | 96 ++++---------------------------------
> gnu/services/mcron.scm | 80 ++++++++++++++-----------------
> 2 files changed, 45 insertions(+), 131 deletions(-)
>
> diff --git a/gnu/home/services/mcron.scm b/gnu/home/services/mcron.scm
> index f51edd6634..23be44ba07 100644
> --- a/gnu/home/services/mcron.scm
> +++ b/gnu/home/services/mcron.scm
> @@ -2,6 +2,7 @@
> ;;; Copyright © 2021, 2023 Andrew Tropin <andrew@trop.in>
> ;;; Copyright © 2021 Xinglu Chen <public@yoctocell.xyz>
> ;;; Copyright © 2022 Maxim Cournoyer <maxim.cournoyer@gmail.com>
> +;;; Copyright © 2023 Ludovic Courtès <ludo@gnu.org>
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -19,16 +20,9 @@
> ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
>
> (define-module (gnu home services mcron)
> - #:use-module (gnu packages guile-xyz)
> #:use-module (gnu home services)
> - #:use-module (gnu services configuration)
> - #:use-module (gnu services shepherd)
> #:use-module (gnu home services shepherd)
> - #:use-module (guix records)
> - #:use-module (guix gexp)
> - #:use-module (srfi srfi-1)
> - #:use-module (ice-9 match)
> -
> + #:use-module (gnu services mcron) ;for the service mapping
> #:export (home-mcron-configuration
> home-mcron-service-type))
>
> @@ -55,86 +49,16 @@ (define-module (gnu home services mcron)
> ;;
> ;;; Code:
>
> -(define list-of-gexps?
> - (list-of gexp?))
> -
> -(define-configuration/no-serialization home-mcron-configuration
> - (mcron (file-like mcron) "The mcron package to use.")
> - (jobs
> - (list-of-gexps '())
> - "This is a list of gexps (@pxref{G-Expressions}), where each gexp
> -corresponds to an mcron job specification (@pxref{Syntax, mcron job
> -specifications,, mcron, GNU@tie{}mcron}).")
> - (log? (boolean #t) "Log messages to standard output.")
> - (log-format
> - (string "~1@*~a ~a: ~a~%")
> - "@code{(ice-9 format)} format string for log messages. The default value
> -produces messages like \"@samp{@var{pid} @var{name}:
> -@var{message}\"} (@pxref{Invoking mcron, Invoking,, mcron, GNU@tie{}mcron}).
> -Each message is also prefixed by a timestamp by GNU Shepherd."))
> -
> -(define job-files (@@ (gnu services mcron) job-files))
> -(define shepherd-schedule-action
> - (@@ (gnu services mcron) shepherd-schedule-action))
> -
> -(define (home-mcron-shepherd-services config)
> - (match-record config <home-mcron-configuration>
> - (mcron jobs log? log-format)
> - (if (null? jobs)
> - '() ;no jobs to run
> - (let ((files (job-files mcron jobs)))
> - (list (shepherd-service
> - (documentation "User cron jobs.")
> - (provision '(mcron))
> - (modules `((srfi srfi-1)
> - (srfi srfi-26)
> - (ice-9 popen) ;for the 'schedule' action
> - (ice-9 rdelim)
> - (ice-9 match)
> - ,@%default-modules))
> - (start #~(make-forkexec-constructor
> - (list (string-append #$mcron "/bin/mcron")
> - #$@(if log?
> - #~("--log" "--log-format" #$log-format)
> - #~())
> - #$@files)
> - #:log-file (string-append
> - (or (getenv "XDG_STATE_HOME")
> - (format #f "~a/.local/state"
> - (getenv "HOME")))
> - "/log/mcron.log")))
> - (stop #~(make-kill-destructor))
> - (actions
> - (list (shepherd-schedule-action mcron files)))))))))
> -
> -(define home-mcron-profile (compose list home-mcron-configuration-mcron))
> -
> -(define (home-mcron-extend config jobs)
> - (home-mcron-configuration
> - (inherit config)
> - (jobs (append (home-mcron-configuration-jobs config)
> - jobs))))
> +(define-syntax-rule (home-mcron-configuration fields ...)
> + ;; Macro provided for backward compatibility.
> + (for-home (mcron-configuration fields ...)))
>
> (define home-mcron-service-type
> - (service-type (name 'home-mcron)
> - (extensions
> - (list (service-extension
> - home-shepherd-service-type
> - home-mcron-shepherd-services)
> - (service-extension
> - home-profile-service-type
> - home-mcron-profile)))
> - (compose concatenate)
> - (extend home-mcron-extend)
> - (default-value (home-mcron-configuration))
> - (description
> - "Install and configure the GNU mcron cron job manager.")))
> + (service-type
> + (inherit (system->home-service-type mcron-service-type))
> + (default-value (for-home (mcron-configuration)))))
>
> -\f
> -;;;
> -;;; Generate documentation.
> -;;;
> -(define (generate-doc)
> - (configuration->documentation 'home-mcron-configuration))
> +(define-service-type-mapping
> + mcron-service-type => home-mcron-service-type)
>
> ;;; mcron.scm ends here
> diff --git a/gnu/services/mcron.scm b/gnu/services/mcron.scm
> index 2ef5980e09..db8b539ff5 100644
> --- a/gnu/services/mcron.scm
> +++ b/gnu/services/mcron.scm
> @@ -1,5 +1,5 @@
> ;;; GNU Guix --- Functional package management for GNU
> -;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
> +;;; Copyright © 2016-2020, 2023 Ludovic Courtès <ludo@gnu.org>
> ;;; Copyright © 2022 Maxim Cournoyer <maxim.cournoyer@gmail.com>
> ;;; Copyright © 2023 Bruno Victal <mirai@makinata.eu>
> ;;;
> @@ -20,10 +20,8 @@
>
> (define-module (gnu services mcron)
> #:use-module (gnu services)
> - #:use-module (gnu services configuration)
> #:use-module (gnu services shepherd)
> #:use-module (gnu packages guile-xyz)
> - #:use-module (guix deprecation)
> #:use-module (guix records)
> #:use-module (guix gexp)
> #:use-module (srfi srfi-1)
> @@ -37,6 +35,7 @@ (define-module (gnu services mcron)
> mcron-configuration-log-file
> mcron-configuration-log-format
> mcron-configuration-date-format
> + mcron-configuration-home-service?
>
> mcron-service-type))
>
> @@ -55,40 +54,34 @@ (define-module (gnu services mcron)
> ;;;
> ;;; Code:
>
> -(define list-of-gexps?
> - (list-of gexp?))
> +;; Configuration of mcron.
> +;; XXX: 'define-configuration' cannot be used here due to the need for
> +;; 'thunked' and 'innate' fields as well as 'this-mcron-configuration'.
> +(define-record-type* <mcron-configuration> mcron-configuration
> + make-mcron-configuration
> + mcron-configuration?
> + this-mcron-configuration
>
> -(define-maybe/no-serialization string)
> + (mcron mcron-configuration-mcron ;file-like
> + (default mcron))
> + (jobs mcron-configuration-jobs ;list of gexps
> + (default '()))
> + (log? mcron-configuration-log? ;Boolean
> + (default #t))
> + (log-file mcron-configuration-log-file ;string | gexp
> + (thunked)
> + (default
> + (if (mcron-configuration-home-service?
> + this-mcron-configuration)
> + #~(string-append %user-log-dir "/mcron.log")
It seems that (modules `((shepherd support))) is missing for this line
to work.
> + "/var/log/mcron.log")))
> + (log-format mcron-configuration-log-format ;string
> + (default "~1@*~a ~a: ~a~%"))
> + (date-format mcron-configuration-date-format ;string | #f
> + (default #f))
>
> -(define-configuration/no-serialization mcron-configuration
> - (mcron
> - (file-like mcron)
> - "The mcron package to use.")
> -
> - (jobs
> - (list-of-gexps '())
> - "This is a list of gexps (@pxref{G-Expressions}), where each gexp
> -corresponds to an mcron job specification (@pxref{Syntax, mcron job
> -specifications,, mcron, GNU@tie{}mcron}).")
> -
> - (log?
> - (boolean #t)
> - "Log messages to standard output.")
> -
> - (log-file
> - (string "/var/log/mcron.log")
> - "Log file location.")
> -
> - (log-format
> - (string "~1@*~a ~a: ~a~%")
> - "@code{(ice-9 format)} format string for log messages. The default value
> -produces messages like @samp{@var{pid} @var{name}: @var{message}}
> -(@pxref{Invoking mcron, Invoking,, mcron, GNU@tie{}mcron}).
> -Each message is also prefixed by a timestamp by GNU Shepherd.")
> -
> - (date-format
> - maybe-string
> - "@code{(srfi srfi-19)} format string for date."))
> + (home-service? mcron-configuration-home-service?
> + (default for-home?) (innate)))
>
> (define (job-files mcron jobs)
> "Return a list of file-like object for JOBS, a list of gexps."
> @@ -158,13 +151,15 @@ (define (shepherd-schedule-action mcron files)
>
> (define (mcron-shepherd-services config)
> (match-record config <mcron-configuration>
> - (mcron jobs log? log-file log-format date-format)
> + (mcron jobs log? log-file log-format date-format home-service?)
> (if (eq? jobs '())
> '() ;nothing to do
> (let ((files (job-files mcron jobs)))
> (list (shepherd-service
> (provision '(mcron))
> - (requirement '(user-processes))
> + (requirement (if home-service?
> + '()
> + '(user-processes)))
> (modules `((srfi srfi-1)
> (srfi srfi-26)
> (ice-9 popen) ;for the 'schedule' action
> @@ -175,7 +170,7 @@ (define (mcron-shepherd-services config)
> (list #$(file-append mcron "/bin/mcron")
> #$@(if log?
> `("--log" "--log-format" ,log-format
> - ,@(if (maybe-value-set? date-format)
> + ,@(if date-format
> (list "--date-format"
> date-format)
> '()))
> @@ -209,15 +204,10 @@ (define mcron-service-type
> (extend (lambda (config jobs)
> (mcron-configuration
> (inherit config)
> + (home-service?
> + (mcron-configuration-home-service? config))
> (jobs (append (mcron-configuration-jobs config)
> jobs)))))
> (default-value (mcron-configuration)))) ;empty job list
>
> -\f
> -;;;
> -;;; Generate documentation.
> -;;;
> -(define (generate-doc)
> - (configuration->documentation 'mcron-configuration))
> -
> ;;; mcron.scm ends here
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 7/8] home: services: Add dicod.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
` (5 preceding siblings ...)
2023-08-06 21:07 ` [bug#65119] [PATCH 6/8] home: services: mcron: Define as a mapping of the system service Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 8/8] home: services: Add Syncthing Ludovic Courtès
2023-08-13 5:28 ` [bug#65119] [PATCH 0/8] Sharing service code between Home and System 宋文武 via Guix-patches via
8 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/home/services/dict.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
* gnu/services/dict.scm (<dicod-configuration>)[home-service?]: New
field.
(dicod-shepherd-service): Do not map /dev/log when 'home-service?' is
true. Remove 'user-processes' requirement when 'home-service?' is
true.
(dicod-shepherd-service): Set #:user and #:group to #f when
'home-service?' is true.
* doc/guix.texi (Miscellaneous Home Services): New node.
(Miscellaneous Services): Add cross-reference.
---
doc/guix.texi | 45 ++++++++++++++++++++++++++++++++++++++
gnu/home/services/dict.scm | 32 +++++++++++++++++++++++++++
gnu/local.mk | 1 +
gnu/services/dict.scm | 27 +++++++++++++++--------
4 files changed, 96 insertions(+), 9 deletions(-)
create mode 100644 gnu/home/services/dict.scm
diff --git a/doc/guix.texi b/doc/guix.texi
index 1d8ebcd72f..dd272636a3 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -446,6 +446,7 @@ Top
* Mail: Mail Home Services. Services for managing mail.
* Messaging: Messaging Home Services. Services for managing messaging.
* Media: Media Home Services. Services for managing media.
+* Miscellaneous: Miscellaneous Home Services. More services.
Platforms
@@ -38723,6 +38724,12 @@ Miscellaneous Services
You can add @command{open localhost} to your @file{~/.dico} file to make
@code{localhost} the default server for @command{dico} client
(@pxref{Initialization File,,, dico, GNU Dico Manual}).
+
+@quotation Note
+This service is also available for Guix Home, where it runs directly
+with your user privileges (@pxref{Miscellaneous Home Services,
+@code{home-dicod-service-type}}).
+@end quotation
@end defvar
@deftp {Data Type} dicod-configuration
@@ -42613,6 +42620,7 @@ Home Services
* Mail: Mail Home Services. Services for managing mail.
* Messaging: Messaging Home Services. Services for managing messaging.
* Media: Media Home Services. Services for managing media.
+* Miscellaneous: Miscellaneous Home Services. More services.
@end menu
@c In addition to that Home Services can provide
@@ -44202,6 +44210,43 @@ Media Home Services
@end table
@end deftp
+@node Miscellaneous Home Services
+@subsection Miscellaneous Home Services
+
+This section lists Home services that lack a better place.
+
+@subsubheading Dictionary Service
+
+@cindex dictionary service, for Home
+The @code{(gnu home services dict)} module provides the following service:
+
+@defvar home-dicod-service-type
+This is the type of the service that runs the @command{dicod} daemon, an
+implementation of DICT server (@pxref{Dicod,,, dico, GNU Dico Manual}).
+
+You can add @command{open localhost} to your @file{~/.dico} file to make
+@code{localhost} the default server for @command{dico} client
+(@pxref{Initialization File,,, dico, GNU Dico Manual}).
+@end defvar
+
+This service is a direct mapping of the @code{dicod-service-type} system
+service (@pxref{Miscellaneous Services, Dictionary Service}). You can
+use it like this:
+
+@lisp
+(service home-dicod-service-type)
+@end lisp
+
+You may specify a custom configuration by providing a
+@code{dicod-configuration} record, exactly like for
+@code{dicod-service-type}, but wrapping it in @code{for-home}:
+
+@lisp
+(service home-dicod-service-type
+ (for-home
+ (dicod-configuration @dots{})))
+@end lisp
+
@node Invoking guix home
@section Invoking @command{guix home}
diff --git a/gnu/home/services/dict.scm b/gnu/home/services/dict.scm
new file mode 100644
index 0000000000..b8a4653276
--- /dev/null
+++ b/gnu/home/services/dict.scm
@@ -0,0 +1,32 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2023 Ludovic Courtès <ludo@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu home services dict)
+ #:use-module (gnu home services)
+ #:use-module (gnu services)
+ #:use-module (gnu services dict)
+ #:use-module ((gnu system shadow) #:select (account-service-type))
+ #:export (home-dicod-service-type)
+ #:re-export (dicod-configuration))
+
+(define home-dicod-service-type
+ (service-type
+ (inherit (system->home-service-type
+ (remove-service-extensions dicod-service-type
+ (list account-service-type))))
+ (default-value (for-home (dicod-configuration)))))
diff --git a/gnu/local.mk b/gnu/local.mk
index f10713f126..b496b53a97 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -91,6 +91,7 @@ GNU_SYSTEM_MODULES = \
%D%/home.scm \
%D%/home/services.scm \
%D%/home/services/desktop.scm \
+ %D%/home/services/dict.scm \
%D%/home/services/symlink-manager.scm \
%D%/home/services/fontutils.scm \
%D%/home/services/gnupg.scm \
diff --git a/gnu/services/dict.scm b/gnu/services/dict.scm
index f542921302..a4e25f5302 100644
--- a/gnu/services/dict.scm
+++ b/gnu/services/dict.scm
@@ -56,7 +56,9 @@ (define-record-type* <dicod-configuration>
(handlers dicod-configuration-handlers ;list of <dicod-handler>
(default '()))
(databases dicod-configuration-databases ;list of <dicod-database>
- (default (list %dicod-database:gcide))))
+ (default (list %dicod-database:gcide)))
+ (home-service? dicod-configuration-home-service? ;boolean
+ (default for-home?) (innate)))
(define-record-type* <dicod-handler>
dicod-handler make-dicod-handler
@@ -152,20 +154,26 @@ (define (dicod-configuration-file config)
(define (dicod-shepherd-service config)
(let* ((dicod.conf (dicod-configuration-file config))
(interfaces (dicod-configuration-interfaces config))
+ (home-service? (dicod-configuration-home-service? config))
+ (mappings `(,@(if home-service?
+ '()
+ (list (file-system-mapping
+ (source "/dev/log")
+ (target source))))
+ ,(file-system-mapping
+ (source dicod.conf)
+ (target source))))
(dicod (least-authority-wrapper
(file-append (dicod-configuration-dico config)
"/bin/dicod")
#:name "dicod"
- #:mappings (list (file-system-mapping
- (source "/dev/log")
- (target source))
- (file-system-mapping
- (source dicod.conf)
- (target source)))
+ #:mappings mappings
#:namespaces (delq 'net %namespaces))))
(list (shepherd-service
(provision '(dicod))
- (requirement '(user-processes))
+ (requirement (if home-service?
+ '()
+ '(user-processes)))
(documentation "Run the dicod daemon.")
(start #~(make-inetd-constructor
(list #$dicod "--inetd" "--foreground"
@@ -176,7 +184,8 @@ (define (dicod-shepherd-service config)
(car (getaddrinfo interface "dict")))))
'#$interfaces)
#:requirements '#$requirement
- #:user "dicod" #:group "dicod"
+ #:user #$(and (not home-service?) "dicod")
+ #:group #$(and (not home-service?) "dicod")
#:service-name-stem "dicod"))
(stop #~(make-inetd-destructor))
(actions (list (shepherd-configuration-action dicod.conf)))))))
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 8/8] home: services: Add Syncthing.
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
` (6 preceding siblings ...)
2023-08-06 21:07 ` [bug#65119] [PATCH 7/8] home: services: Add dicod Ludovic Courtès
@ 2023-08-06 21:07 ` Ludovic Courtès
2023-08-13 5:28 ` [bug#65119] [PATCH 0/8] Sharing service code between Home and System 宋文武 via Guix-patches via
8 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-06 21:07 UTC (permalink / raw)
To: 65119; +Cc: Ludovic Courtès
* gnu/home/services/syncthing.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
* gnu/services/syncthing.scm (<syncthing-configuration>)[home-service?]:
New field.
Adjust 'provision' and 'requirement' depending on 'home-service?', and
likewise for #:user and #:group.
Use 'filter' + 'negate' instead of 'remove'.
* doc/guix.texi (Networking Services): Add note and cross-reference to
"Networking Home Services".
(Networking Home Services): New node.
---
doc/guix.texi | 51 ++++++++++++++++++++++++++++++++-
gnu/home/services/syncthing.scm | 30 +++++++++++++++++++
gnu/local.mk | 1 +
gnu/services/syncthing.scm | 26 ++++++++++-------
4 files changed, 97 insertions(+), 11 deletions(-)
create mode 100644 gnu/home/services/syncthing.scm
diff --git a/doc/guix.texi b/doc/guix.texi
index dd272636a3..a4993b7ae7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -446,6 +446,7 @@ Top
* Mail: Mail Home Services. Services for managing mail.
* Messaging: Messaging Home Services. Services for managing messaging.
* Media: Media Home Services. Services for managing media.
+* Networking: Networking Home Services. Networking services.
* Miscellaneous: Miscellaneous Home Services. More services.
Platforms
@@ -21226,6 +21227,8 @@ Networking Services
@end table
@end deftp
+@cindex Syncthing, file synchronization service
+@cindex backup service, Syncthing
The @code{(gnu services syncthing)} module provides the following services:
@cindex syncthing
@@ -21243,7 +21246,14 @@ Networking Services
(syncthing-configuration (user "alice")))
@end lisp
+@quotation Note
+This service is also available for Guix Home, where it runs directly
+with your user privileges (@pxref{Networking Home Services,
+@code{home-syncthing-service-type}}).
+@end quotation
+
See below for details about @code{syncthing-configuration}.
+@end defvar
@deftp {Data Type} syncthing-configuration
Data type representing the configuration for @code{syncthing-service-type}.
@@ -21273,7 +21283,6 @@ Networking Services
@end table
@end deftp
-@end defvar
Furthermore, @code{(gnu services ssh)} provides the following services.
@cindex SSH
@@ -42620,6 +42629,7 @@ Home Services
* Mail: Mail Home Services. Services for managing mail.
* Messaging: Messaging Home Services. Services for managing messaging.
* Media: Media Home Services. Services for managing media.
+* Networking: Networking Home Services. Networking services.
* Miscellaneous: Miscellaneous Home Services. More services.
@end menu
@c In addition to that Home Services can provide
@@ -44210,6 +44220,45 @@ Media Home Services
@end table
@end deftp
+@node Networking Home Services
+@subsection Networking Home Services
+
+This section lists services somewhat networking-related that you may use
+with Guix Home.
+
+@cindex Syncthing, file synchronization service
+@cindex backup service, Syncthing
+The @code{(gnu home services syncthing)} module provides a service to
+set up the @uref{Syncthing, https://syncthing.net} continuous file
+backup service.
+
+@defvar home-syncthing-service-type
+This is the service type for the @command{syncthing} daemon; it is the
+Home counterpart of the @code{syncthing-service-type} system service
+(@pxref{Networking Services, @code{syncthing-service-type}}). The value
+for this service type is a @command{syncthing-configuration}.
+
+Here is how you would set it up with the default configuration:
+
+@lisp
+(service home-syncthing-service-type)
+@end lisp
+
+For a custom configuration, wrap you @code{syncthing-configuration} in
+@code{for-home}, as in this example:
+
+@lisp
+(service home-syncthing-service-type
+ (for-home
+ (syncthing-configuration (logflags 5))))
+@end lisp
+
+For details about @code{syncthing-configuration}, check out the
+documentation of the system service (@pxref{Networking Services,
+@code{syncthing-service-type}}).
+@end defvar
+
+
@node Miscellaneous Home Services
@subsection Miscellaneous Home Services
diff --git a/gnu/home/services/syncthing.scm b/gnu/home/services/syncthing.scm
new file mode 100644
index 0000000000..9c9eb94ea1
--- /dev/null
+++ b/gnu/home/services/syncthing.scm
@@ -0,0 +1,30 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2023 Ludovic Courtès <ludo@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu home services syncthing)
+ #:use-module (gnu services)
+ #:use-module (gnu home services)
+ #:use-module (gnu services syncthing)
+ #:export (home-syncthing-service-type)
+ #:re-export (syncthing-configuration
+ syncthing-configuration?))
+
+(define home-syncthing-service-type
+ (service-type
+ (inherit (system->home-service-type syncthing-service-type))
+ (default-value (for-home (syncthing-configuration)))))
diff --git a/gnu/local.mk b/gnu/local.mk
index b496b53a97..d98ecfb7b4 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -104,6 +104,7 @@ GNU_SYSTEM_MODULES = \
%D%/home/services/shepherd.scm \
%D%/home/services/sound.scm \
%D%/home/services/ssh.scm \
+ %D%/home/services/syncthing.scm \
%D%/home/services/mcron.scm \
%D%/home/services/utils.scm \
%D%/home/services/xdg.scm \
diff --git a/gnu/services/syncthing.scm b/gnu/services/syncthing.scm
index 8f94aef088..f97a1a2ff4 100644
--- a/gnu/services/syncthing.scm
+++ b/gnu/services/syncthing.scm
@@ -48,32 +48,38 @@ (define-record-type* <syncthing-configuration>
(group syncthing-configuration-group ;string
(default "users"))
(home syncthing-configuration-home ;string
- (default #f)))
+ (default #f))
+ (home-service? syncthing-configuration-home-service?
+ (default for-home?) (innate)))
(define syncthing-shepherd-service
(match-record-lambda <syncthing-configuration>
- (syncthing arguments logflags user group home)
+ (syncthing arguments logflags user group home home-service?)
(list
(shepherd-service
- (provision (list (string->symbol (string-append "syncthing-" user))))
+ (provision (if home-service?
+ '(syncthing)
+ (list (string->symbol
+ (string-append "syncthing-" user)))))
(documentation "Run syncthing.")
- (requirement '(loopback))
+ (requirement (if home-service? '() '(loopback)))
(start #~(make-forkexec-constructor
(append (list (string-append #$syncthing "/bin/syncthing")
"-no-browser"
"-no-restart"
(string-append "-logflags=" (number->string #$logflags)))
'#$arguments)
- #:user #$user
- #:group #$group
+ #:user #$(and (not home-service?) user)
+ #:group #$(and (not home-service?) group)
#:environment-variables
(append (list (string-append "HOME=" (or #$home (passwd:dir (getpw #$user))))
"SSL_CERT_DIR=/etc/ssl/certs"
"SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt")
- (remove (lambda (str)
- (or (string-prefix? "HOME=" str)
- (string-prefix? "SSL_CERT_DIR=" str)
- (string-prefix? "SSL_CERT_FILE=" str)))
+ (filter (negate ;XXX: 'remove' is not in (guile)
+ (lambda (str)
+ (or (string-prefix? "HOME=" str)
+ (string-prefix? "SSL_CERT_DIR=" str)
+ (string-prefix? "SSL_CERT_FILE=" str))))
(environ)))))
(respawn? #f)
(stop #~(make-kill-destructor))))))
--
2.41.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
` (7 preceding siblings ...)
2023-08-06 21:07 ` [bug#65119] [PATCH 8/8] home: services: Add Syncthing Ludovic Courtès
@ 2023-08-13 5:28 ` 宋文武 via Guix-patches via
2023-08-20 21:23 ` bug#65119: " Ludovic Courtès
2023-08-21 13:43 ` [bug#65119] " Andrew Tropin
8 siblings, 2 replies; 25+ messages in thread
From: 宋文武 via Guix-patches via @ 2023-08-13 5:28 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 65119, Ludovic Courtès, Andrew Tropin, paren
Ludovic Courtès <ludo@gnu.org> writes:
> [...]
>
> This patch lets us map System services to Home and uses the new
> mechanism for three services: mcron, dicod, and syncthing.
>
> services: dicod: Remove Shepherd < 0.9.0 compatibility layer.
> services: dicod: Pre-build the GCIDE index.
> services: syncthing: Use 'match-record'.
> services: Define 'for-home'.
> home: services: Support mapping of System services to Home services.
> home: services: mcron: Define as a mapping of the system service.
> home: services: Add dicod.
> home: services: Add Syncthing.
I didn't test them, but those changes look good to me!
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#65119: [PATCH 0/8] Sharing service code between Home and System
2023-08-13 5:28 ` [bug#65119] [PATCH 0/8] Sharing service code between Home and System 宋文武 via Guix-patches via
@ 2023-08-20 21:23 ` Ludovic Courtès
2023-08-21 13:43 ` [bug#65119] " Andrew Tropin
1 sibling, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-20 21:23 UTC (permalink / raw)
To: 宋文武; +Cc: paren, 65119-done, Andrew Tropin
Hi,
宋文武 <iyzsong@envs.net> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> [...]
>>
>> This patch lets us map System services to Home and uses the new
>> mechanism for three services: mcron, dicod, and syncthing.
>>
>> services: dicod: Remove Shepherd < 0.9.0 compatibility layer.
>> services: dicod: Pre-build the GCIDE index.
>> services: syncthing: Use 'match-record'.
>> services: Define 'for-home'.
>> home: services: Support mapping of System services to Home services.
>> home: services: mcron: Define as a mapping of the system service.
>> home: services: Add dicod.
>> home: services: Add Syncthing.
>
> I didn't test them, but those changes look good to me!
Pushed as 7605c01fccb20b387f5a0d98d6b81074b3039e23, thanks for taking a
look!
Ludo’.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-08-13 5:28 ` [bug#65119] [PATCH 0/8] Sharing service code between Home and System 宋文武 via Guix-patches via
2023-08-20 21:23 ` bug#65119: " Ludovic Courtès
@ 2023-08-21 13:43 ` Andrew Tropin
2023-08-22 16:25 ` Ludovic Courtès
1 sibling, 1 reply; 25+ messages in thread
From: Andrew Tropin @ 2023-08-21 13:43 UTC (permalink / raw)
To: 宋文武, Ludovic Courtès
Cc: 65119, Ludovic Courtès, paren
[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]
On 2023-08-13 13:28, 宋文武 wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> [...]
>>
>> This patch lets us map System services to Home and uses the new
>> mechanism for three services: mcron, dicod, and syncthing.
>>
>> services: dicod: Remove Shepherd < 0.9.0 compatibility layer.
>> services: dicod: Pre-build the GCIDE index.
>> services: syncthing: Use 'match-record'.
>> services: Define 'for-home'.
>> home: services: Support mapping of System services to Home services.
>> home: services: mcron: Define as a mapping of the system service.
>> home: services: Add dicod.
>> home: services: Add Syncthing.
>
> I didn't test them, but those changes look good to me!
Hi Ludovic, 宋文武!
Sorry for comming late to the party, I saw this message only a week ago
and didn't have time to make an extensive reply yet, so I will share my
quick thought on the most problematic part and maybe later will
formulate others thoughts in more details.
define-service-type-mapping looks imperative and potentially very
problematic. Collecting those values in unknown order and applying this
implicit transformation making a good room for foot shooting. Imagine
someone would like to use his own (let's say) shepherd home service
implementation and will add this to one of the source files of their
channel:
--8<---------------cut here---------------start------------->8---
(define-service-type-mapping
shepherd-root-service-type => my-home-shepherd-service-type)
--8<---------------cut here---------------end--------------->8---
What happens if somebody will use his channel just for getting some
package? Very likely it would break the build or in the worst case it
will build with unexpected service implementation under the hood.
I had [1][2] and still have concerns about macros and records
composability and reusability. I personally don't like excessive usage
of them in general. By adding more macros, already quite complex guix
services mechanism becomes even more harder to learn, inspect, reason
about and work with. In addition to that it has a major technical issue
mentioned above. I'm strongly against this change and would suggest to
revert it.
I hope it doesn't sound rude and I'm really thankful for your work on
this, but I just think it's not the right solution, at least yet, in its
current form.
[1]: https://yhetil.org/guix-devel/878rvp1deg.fsf@trop.in/T/#u
[2]: https://yhetil.org/87ild88kax.fsf@trop.in
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-08-21 13:43 ` [bug#65119] " Andrew Tropin
@ 2023-08-22 16:25 ` Ludovic Courtès
2023-08-25 6:28 ` Andrew Tropin
0 siblings, 1 reply; 25+ messages in thread
From: Ludovic Courtès @ 2023-08-22 16:25 UTC (permalink / raw)
To: Andrew Tropin; +Cc: 65119, 宋文武, paren
Hi Andrew,
Andrew Tropin <andrew@trop.in> skribis:
> Sorry for comming late to the party, I saw this message only a week ago
> and didn't have time to make an extensive reply yet, so I will share my
> quick thought on the most problematic part and maybe later will
> formulate others thoughts in more details.
>
> define-service-type-mapping looks imperative and potentially very
> problematic. Collecting those values in unknown order and applying this
> implicit transformation making a good room for foot shooting. Imagine
> someone would like to use his own (let's say) shepherd home service
> implementation and will add this to one of the source files of their
> channel:
>
> (define-service-type-mapping
> shepherd-root-service-type => my-home-shepherd-service-type)
>
> What happens if somebody will use his channel just for getting some
> package? Very likely it would break the build or in the worst case it
> will build with unexpected service implementation under the hood.
Yes, this is always possible. Though it’s not very different from:
(set! home-shepherd-service-type …)
Maybe the unintended effect is more likely to happen unwillingly though,
maybe.
Do you have other solutions in mind, be it for this specific issue or
for system/home service mapping in general?
> I had [1][2] and still have concerns about macros and records
> composability and reusability. I personally don't like excessive usage
> of them in general. By adding more macros, already quite complex guix
> services mechanism becomes even more harder to learn, inspect, reason
> about and work with. In addition to that it has a major technical issue
> mentioned above. I'm strongly against this change and would suggest to
> revert it.
>
> I hope it doesn't sound rude and I'm really thankful for your work on
> this, but I just think it's not the right solution, at least yet, in its
> current form.
It does sound a bit rude. :-) I would have loved to get any feedback
from you while we were discussing this in the course of reviewing the
Syncthing and Dicod patches a couple of months ago (which I believe you
were Cc’d on, as member of the Home team).
I won’t argue about macros and records, it’s off-topic: macros and
records are part of the Schemer’s toolbox, we try and use them wisely,
and Guix code has always used macros and records. We can discuss
whether a specific macro or record type is suitable, of course, but
general statements about them are unhelpful.
Was it ‘for-home’ that triggered your comment?
The patches do not introduce any new record type IIRC; what triggered
your comment regarding records?
I’m all for making changes to improve on this patch series. I’m against
reverting the patch series: the conditions for reverting are not met
(info "(guix) Commit Access").
Thanks for your feedback,
Ludo’.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-08-22 16:25 ` Ludovic Courtès
@ 2023-08-25 6:28 ` Andrew Tropin
2023-09-08 12:42 ` Andrew Tropin
2023-09-08 22:18 ` Ludovic Courtès
0 siblings, 2 replies; 25+ messages in thread
From: Andrew Tropin @ 2023-08-25 6:28 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 65119, 宋文武, paren
[-- Attachment #1: Type: text/plain, Size: 5098 bytes --]
On 2023-08-22 18:25, Ludovic Courtès wrote:
> Hi Andrew,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> Sorry for comming late to the party, I saw this message only a week ago
>> and didn't have time to make an extensive reply yet, so I will share my
>> quick thought on the most problematic part and maybe later will
>> formulate others thoughts in more details.
>>
>> define-service-type-mapping looks imperative and potentially very
>> problematic. Collecting those values in unknown order and applying this
>> implicit transformation making a good room for foot shooting. Imagine
>> someone would like to use his own (let's say) shepherd home service
>> implementation and will add this to one of the source files of their
>> channel:
>>
>> (define-service-type-mapping
>> shepherd-root-service-type => my-home-shepherd-service-type)
>>
>> What happens if somebody will use his channel just for getting some
>> package? Very likely it would break the build or in the worst case it
>> will build with unexpected service implementation under the hood.
>
> Yes, this is always possible. Though it’s not very different from:
>
> (set! home-shepherd-service-type …)
Yes, and and this is exactly what this solution does and in addition to
that it hides it under the sweet define-service-type-mapping interface.
`set!` explicitly communicates the danger of usage,
define-service-type-mapping does not.
1. We introduce a global state here and infect potentially all the
modules from all channels with it + mask it with nice interface. => Now
the result of evaluation depends on the order source files are read.
Every channel can break valid user's configurations with perfectly legal
public guix API. We make reloading of the modules and REPL-driven
development in general a huge pain in the lower back.
2. The service extension mechanism is already quite complex to understand
on its own, in addition to that the devirsity of record creation macros
/ DSLs (define-record-type, define-record-type*, define-configuration)
doesn't make the situation better. We introduce one more DSL on top of
couple existing. => Learning curve raises even higher. Inspecting,
navigating and debugging such code becomes harder. It prevents future
extension with for-container or for-development-environment. It saves
couple of lines and avoids some minor repetions at the moment, but not
sure that it's the right way to reuse the stuff between home and system
services.
>
> Maybe the unintended effect is more likely to happen unwillingly though,
> maybe.
>
> Do you have other solutions in mind, be it for this specific issue or
> for system/home service mapping in general?
>
>> I had [1][2] and still have concerns about macros and records
>> composability and reusability. I personally don't like excessive usage
>> of them in general. By adding more macros, already quite complex guix
>> services mechanism becomes even more harder to learn, inspect, reason
>> about and work with. In addition to that it has a major technical issue
>> mentioned above. I'm strongly against this change and would suggest to
>> revert it.
>>
>> I hope it doesn't sound rude and I'm really thankful for your work on
>> this, but I just think it's not the right solution, at least yet, in its
>> current form.
>
> It does sound a bit rude. :-) I would have loved to get any feedback
> from you while we were discussing this in the course of reviewing the
> Syncthing and Dicod patches a couple of months ago (which I believe you
> were Cc’d on, as member of the Home team).
>
> I won’t argue about macros and records, it’s off-topic: macros and
> records are part of the Schemer’s toolbox, we try and use them wisely,
> and Guix code has always used macros and records. We can discuss
> whether a specific macro or record type is suitable, of course, but
> general statements about them are unhelpful.
>
Actually, it's quite on-topic IMO and it seems as a consequence of the
abandoned discussions I linked earlier, but it's a long story and we can
keep it aside for now, because despite the reasons lead to this solution
it has fundamental problems on its own we better to focus on. Maybe
later I'll elaborate on my thought process in more details.
> Was it ‘for-home’ that triggered your comment?
>
> The patches do not introduce any new record type IIRC; what triggered
> your comment regarding records?
>
> I’m all for making changes to improve on this patch series. I’m against
> reverting the patch series: the conditions for reverting are not met
> (info "(guix) Commit Access").
>
> Thanks for your feedback,
> Ludo’.
Please treat it with adjustment to my not very proficient level of
english and lacking ability to express nuances. It's not a personal
critique in any way, it's my roughly formulated concerns on 1. technical
aspects of the solution and 2. possible consequences for the future of
guix and its user-facing API.
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-08-25 6:28 ` Andrew Tropin
@ 2023-09-08 12:42 ` Andrew Tropin
2023-09-08 22:18 ` Ludovic Courtès
1 sibling, 0 replies; 25+ messages in thread
From: Andrew Tropin @ 2023-09-08 12:42 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 65119, 宋文武, paren
[-- Attachment #1: Type: text/plain, Size: 5846 bytes --]
On 2023-08-25 10:28, Andrew Tropin wrote:
> On 2023-08-22 18:25, Ludovic Courtès wrote:
>
>> Hi Andrew,
>>
>> Andrew Tropin <andrew@trop.in> skribis:
>>
>>> Sorry for comming late to the party, I saw this message only a week ago
>>> and didn't have time to make an extensive reply yet, so I will share my
>>> quick thought on the most problematic part and maybe later will
>>> formulate others thoughts in more details.
>>>
>>> define-service-type-mapping looks imperative and potentially very
>>> problematic. Collecting those values in unknown order and applying this
>>> implicit transformation making a good room for foot shooting. Imagine
>>> someone would like to use his own (let's say) shepherd home service
>>> implementation and will add this to one of the source files of their
>>> channel:
>>>
>>> (define-service-type-mapping
>>> shepherd-root-service-type => my-home-shepherd-service-type)
>>>
>>> What happens if somebody will use his channel just for getting some
>>> package? Very likely it would break the build or in the worst case it
>>> will build with unexpected service implementation under the hood.
>>
>> Yes, this is always possible. Though it’s not very different from:
>>
>> (set! home-shepherd-service-type …)
>
> Yes, and and this is exactly what this solution does and in addition to
> that it hides it under the sweet define-service-type-mapping interface.
> `set!` explicitly communicates the danger of usage,
> define-service-type-mapping does not.
>
>
> 1. We introduce a global state here and infect potentially all the
> modules from all channels with it + mask it with nice interface. =>
To support my previous suggestion to revert this patch series I will
document the example of a consequence:
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=cf6abf50dbbbd95fef465ab4bb3b608843ac47e1
https://issues.guix.gnu.org/65510
It highlights this:
> Now the result of evaluation depends on the order source files are
> read.
>>> Collecting those values in unknown order and applying this
>>> implicit transformation making a good room for foot shooting.
to say it differently this change introduced the implicit dependency on
the fact of the evaluation of the form, which is not explicitly
referenced anywhere.
> Every channel can break valid user's configurations with perfectly
> legal public guix API. We make reloading of the modules and
> REPL-driven development in general a huge pain in the lower back.
>
> 2. The service extension mechanism is already quite complex to understand
> on its own, in addition to that the devirsity of record creation macros
> / DSLs (define-record-type, define-record-type*, define-configuration)
> doesn't make the situation better. We introduce one more DSL on top of
> couple existing. => Learning curve raises even higher. Inspecting,
> navigating and debugging such code becomes harder. It prevents future
> extension with for-container or for-development-environment. It saves
> couple of lines and avoids some minor repetions at the moment, but not
> sure that it's the right way to reuse the stuff between home and system
> services.
>
>>
>> Maybe the unintended effect is more likely to happen unwillingly though,
>> maybe.
>>
>> Do you have other solutions in mind, be it for this specific issue or
>> for system/home service mapping in general?
>>
>>> I had [1][2] and still have concerns about macros and records
>>> composability and reusability. I personally don't like excessive usage
>>> of them in general. By adding more macros, already quite complex guix
>>> services mechanism becomes even more harder to learn, inspect, reason
>>> about and work with. In addition to that it has a major technical issue
>>> mentioned above. I'm strongly against this change and would suggest to
>>> revert it.
>>>
>>> I hope it doesn't sound rude and I'm really thankful for your work on
>>> this, but I just think it's not the right solution, at least yet, in its
>>> current form.
>>
>> It does sound a bit rude. :-) I would have loved to get any feedback
>> from you while we were discussing this in the course of reviewing the
>> Syncthing and Dicod patches a couple of months ago (which I believe you
>> were Cc’d on, as member of the Home team).
>>
>> I won’t argue about macros and records, it’s off-topic: macros and
>> records are part of the Schemer’s toolbox, we try and use them wisely,
>> and Guix code has always used macros and records. We can discuss
>> whether a specific macro or record type is suitable, of course, but
>> general statements about them are unhelpful.
>>
>
> Actually, it's quite on-topic IMO and it seems as a consequence of the
> abandoned discussions I linked earlier, but it's a long story and we can
> keep it aside for now, because despite the reasons lead to this solution
> it has fundamental problems on its own we better to focus on. Maybe
> later I'll elaborate on my thought process in more details.
>
>> Was it ‘for-home’ that triggered your comment?
>>
>> The patches do not introduce any new record type IIRC; what triggered
>> your comment regarding records?
>>
>> I’m all for making changes to improve on this patch series. I’m against
>> reverting the patch series: the conditions for reverting are not met
>> (info "(guix) Commit Access").
>>
>> Thanks for your feedback,
>> Ludo’.
>
> Please treat it with adjustment to my not very proficient level of
> english and lacking ability to express nuances. It's not a personal
> critique in any way, it's my roughly formulated concerns on 1. technical
> aspects of the solution and 2. possible consequences for the future of
> guix and its user-facing API.
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-08-25 6:28 ` Andrew Tropin
2023-09-08 12:42 ` Andrew Tropin
@ 2023-09-08 22:18 ` Ludovic Courtès
2023-09-09 10:42 ` Andrew Tropin
1 sibling, 1 reply; 25+ messages in thread
From: Ludovic Courtès @ 2023-09-08 22:18 UTC (permalink / raw)
To: Andrew Tropin; +Cc: 65119, 宋文武, paren
Hi Andrew,
Andrew Tropin <andrew@trop.in> skribis:
> Yes, and and this is exactly what this solution does and in addition to
> that it hides it under the sweet define-service-type-mapping interface.
> `set!` explicitly communicates the danger of usage,
> define-service-type-mapping does not.
>
>
> 1. We introduce a global state here and infect potentially all the
> modules from all channels with it + mask it with nice interface. => Now
> the result of evaluation depends on the order source files are read.
> Every channel can break valid user's configurations with perfectly legal
> public guix API. We make reloading of the modules and REPL-driven
> development in general a huge pain in the lower back.
>
>
> 2. The service extension mechanism is already quite complex to understand
> on its own, in addition to that the devirsity of record creation macros
> / DSLs (define-record-type, define-record-type*, define-configuration)
> doesn't make the situation better. We introduce one more DSL on top of
> couple existing. => Learning curve raises even higher. Inspecting,
> navigating and debugging such code becomes harder. It prevents future
> extension with for-container or for-development-environment. It saves
> couple of lines and avoids some minor repetions at the moment, but not
> sure that it's the right way to reuse the stuff between home and system
> services.
I understand what you’re saying. I don’t necessarily agree with all of
it because I believe abstraction is a fundamental part of programming;
abstractions can sometimes be wrong or misleading of course, and that’s
what we should strive to avoid.
Back to this patch series, we’ve had one concrete illustration of a
shortcoming:
https://issues.guix.gnu.org/65510
I’m aware of this and agree it needs to be addressed.
In assessing this patch series, one should keep in mind that it solves a
longstanding issue with Guix Home (code duplication and the inability to
share service code with Guix System), one for which no other solution
was proposed AFAIK.
My own assessment, having reviewed patches adding Home services (in all
loneliness I must say) is that the outcome is positive, in spite of the
shortcoming mentioned above.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-09-08 22:18 ` Ludovic Courtès
@ 2023-09-09 10:42 ` Andrew Tropin
2023-09-13 18:06 ` Ludovic Courtès
2023-09-13 19:55 ` Ludovic Courtès
0 siblings, 2 replies; 25+ messages in thread
From: Andrew Tropin @ 2023-09-09 10:42 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 65119, 宋文武, paren
[-- Attachment #1: Type: text/plain, Size: 5687 bytes --]
On 2023-09-09 00:18, Ludovic Courtès wrote:
> Hi Andrew,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> Yes, and and this is exactly what this solution does and in addition to
>> that it hides it under the sweet define-service-type-mapping interface.
>> `set!` explicitly communicates the danger of usage,
>> define-service-type-mapping does not.
>>
>>
>> 1. We introduce a global state here and infect potentially all the
>> modules from all channels with it + mask it with nice interface. => Now
>> the result of evaluation depends on the order source files are read.
>> Every channel can break valid user's configurations with perfectly legal
>> public guix API. We make reloading of the modules and REPL-driven
>> development in general a huge pain in the lower back.
>>
>>
>> 2. The service extension mechanism is already quite complex to understand
>> on its own, in addition to that the devirsity of record creation macros
>> / DSLs (define-record-type, define-record-type*, define-configuration)
>> doesn't make the situation better. We introduce one more DSL on top of
>> couple existing. => Learning curve raises even higher. Inspecting,
>> navigating and debugging such code becomes harder. It prevents future
>> extension with for-container or for-development-environment. It saves
>> couple of lines and avoids some minor repetions at the moment, but not
>> sure that it's the right way to reuse the stuff between home and system
>> services.
>
> I understand what you’re saying. I don’t necessarily agree with all of
> it because I believe abstraction is a fundamental part of programming;
> abstractions can sometimes be wrong or misleading of course, and that’s
> what we should strive to avoid.
>
> Back to this patch series, we’ve had one concrete illustration of a
> shortcoming:
>
> https://issues.guix.gnu.org/65510
>
> I’m aware of this and agree it needs to be addressed.
>
> In assessing this patch series, one should keep in mind that it solves a
> longstanding issue with Guix Home (code duplication and the inability to
> share service code with Guix System), one for which no other solution
> was proposed AFAIK.
1. One of the possible options is to use free-style configurations for
services, so we can reuse a lot of code and drastically decrease
duplication (only the service definition itself and a one configuration
record) and maintanance burden.
https://yhetil.org/guix/87ild88kax.fsf@trop.in/
We have only two maintainers and have more than the half of a hundred
services in rde, which is not that far from guix itself (258 services).
2. Another option is to rethink service extension mechanism a little bit
and maybe make it more polymorphic.
https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E
(Just making a rough example of naive implementation) Instead of
referencing service by it's value, we could reference its name. This
way we can write one service for Home and System, which always extends
'system-accounts-service-type, and for home case provide a different
implementation for it, so when we build operating system
system-accounts-service-type will add users to /etc/passwd, when we
build home-environment system-accounts-service-type will do nothing.
Adjusting the logic of the extension based on presence/absence of a
particular service can be very useful to make it possible to reuse
configuration for Home and System services directly.
However, improving service extension mechanism in such way, keeping
backward compatibility and upstreaming it is a hard and very
time-consuming task. So in rde we just implemented a feature mechanism
on top of service extension mechanism to solve challenges mentioned
above and it works great. It would be even greater if we could just do
the same with plain services.
My point here is: let's solve this issue on another level of
abstraction, by improving service extension mechanism, not by creating a
new level of abstraction (as we did in rde or in this patch series) to
cover the wholes in the previous level. I would be glad to cooperate on
this and design possible improvements.
> My own assessment, having reviewed patches adding Home services (in all
> loneliness I must say) is that the outcome is positive, in spite of the
> shortcoming mentioned above.
> in all loneliness I must say
In some previous threads on guix-devel/guix-patches I mentioned, that we
will maintain home services for rde separately
https://git.sr.ht/~abcdw/rde/tree/master/item/doc/decision-log/0004-rde-flavor-guix-services.org
and thus all (most of) the home services coming to guix-patches won't be
used by rde or me personally. Despite the fact that I would be glad to
help with reviews, I already work hard (almost fulltime) on guix, guile
and emacs ecosystem in parrallel to running from the war and probably
reviewing home services on guix-patches is less valuable use of my time
both for me and for the community.
> In assessing this patch series, one should keep in mind that it solves a
> longstanding issue with Guix Home (code duplication and the inability to
> share service code with Guix System), one for which no other solution
> was proposed AFAIK.
I think that your concern about code duplication is valid (and I'm aware
of the issue probably even longer :) ) and I would be glad to cooperate
to solve it. However, I'm almost sure that it should be done on service
extension mechanism level. If this make sense, we can discuss possible
solutions in more details and next practical steps.
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-09-09 10:42 ` Andrew Tropin
@ 2023-09-13 18:06 ` Ludovic Courtès
2023-09-17 5:28 ` Andrew Tropin
2023-09-13 19:55 ` Ludovic Courtès
1 sibling, 1 reply; 25+ messages in thread
From: Ludovic Courtès @ 2023-09-13 18:06 UTC (permalink / raw)
To: Andrew Tropin; +Cc: 65119, 宋文武, paren
Hi,
Andrew Tropin <andrew@trop.in> skribis:
> In some previous threads on guix-devel/guix-patches I mentioned, that we
> will maintain home services for rde separately
> https://git.sr.ht/~abcdw/rde/tree/master/item/doc/decision-log/0004-rde-flavor-guix-services.org
> and thus all (most of) the home services coming to guix-patches won't be
> used by rde or me personally. Despite the fact that I would be glad to
> help with reviews, I already work hard (almost fulltime) on guix, guile
> and emacs ecosystem in parrallel to running from the war and probably
> reviewing home services on guix-patches is less valuable use of my time
> both for me and for the community.
Then, for clarity and to avoid misunderstandings, perhaps you should
remove yourself from the Home team?
I’m disappointed that rde/Guix cooperation is a one-way street.
Ludo’.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-09-13 18:06 ` Ludovic Courtès
@ 2023-09-17 5:28 ` Andrew Tropin
2023-09-17 10:27 ` Ludovic Courtès
0 siblings, 1 reply; 25+ messages in thread
From: Andrew Tropin @ 2023-09-17 5:28 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 65119, 宋文武, paren
[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]
On 2023-09-13 20:06, Ludovic Courtès wrote:
> Hi,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> In some previous threads on guix-devel/guix-patches I mentioned, that we
>> will maintain home services for rde separately
>> https://git.sr.ht/~abcdw/rde/tree/master/item/doc/decision-log/0004-rde-flavor-guix-services.org
>> and thus all (most of) the home services coming to guix-patches won't be
>> used by rde or me personally. Despite the fact that I would be glad to
>> help with reviews, I already work hard (almost fulltime) on guix, guile
>> and emacs ecosystem in parrallel to running from the war and probably
>> reviewing home services on guix-patches is less valuable use of my time
>> both for me and for the community.
>
> I’m disappointed that rde/Guix cooperation is a one-way street.
That's probably a wrong statement. rde creates, integrates and
innovates a bunch of good tools, tests and often upstreams them;
contributes back a lot of changes and packages, popularizes and
encriches guix and neighbour ecosystems and helps to finish stale
projects/issues in guix mailing lists, ranging from Wayland, Emacs,
Pipewire, iwd related to Tree-sitter, Guix Home and couple other
non-trivial thing.
rde definetly benifit from all the great work done in Guix, but it's
kinda offensive to say that it's one-way street.
> Then, for clarity and to avoid misunderstandings, perhaps you should
> remove yourself from the Home team?
>
I guess this one I've already sent to you an year ago is still true:
--8<---------------cut here---------------start------------->8---
However, I perfectly understand the reasons for Guix System style
services and respect your descion and desire to stick with them. I
mentioned that I'll maintain already existing rde style services in rde
and it won't make sense for me to upstream most of them from rde to
Guix, because it will mean almost complete rewrite for them.
And this is another reason I don't participate in development of home
services, because it will mean double or even triple work for me,
however I keep an eye on patches you send, in most cases someone jumps
in earlier with review, so I don't bother you with my comments. But
development of Guix Home itself and the rest of Guix is a part of my
interests.
--8<---------------cut here---------------end--------------->8---
I do want to get CCed on general Guix Home topics, I'm ok with getting
CCed on other guix home patches and threads outside of my
interests/workload capabilities.
If you think that confusion is severe, we can split the team into Guix
Home Core and Guix Home Services, however I don't think it makes a lot
of sence.
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-09-17 5:28 ` Andrew Tropin
@ 2023-09-17 10:27 ` Ludovic Courtès
0 siblings, 0 replies; 25+ messages in thread
From: Ludovic Courtès @ 2023-09-17 10:27 UTC (permalink / raw)
To: Andrew Tropin; +Cc: 65119, 宋文武, paren
Hi
Andrew Tropin <andrew@trop.in> skribis:
> On 2023-09-13 20:06, Ludovic Courtès wrote:
>
>> Hi,
>>
>> Andrew Tropin <andrew@trop.in> skribis:
>>
>>> In some previous threads on guix-devel/guix-patches I mentioned, that we
>>> will maintain home services for rde separately
[...]
>> I’m disappointed that rde/Guix cooperation is a one-way street.
>
> That's probably a wrong statement.
That was a reaction to “we will maintain home services for rde
separately” above; to me that statement was unambiguous.
[...]
>> Then, for clarity and to avoid misunderstandings, perhaps you should
>> remove yourself from the Home team?
>>
>
> I guess this one I've already sent to you an year ago is still true:
>
> However, I perfectly understand the reasons for Guix System style
> services and respect your descion and desire to stick with them. I
> mentioned that I'll maintain already existing rde style services in rde
> and it won't make sense for me to upstream most of them from rde to
> Guix, because it will mean almost complete rewrite for them.
>
> And this is another reason I don't participate in development of home
> services, because it will mean double or even triple work for me,
> however I keep an eye on patches you send, in most cases someone jumps
> in earlier with review, so I don't bother you with my comments. But
> development of Guix Home itself and the rest of Guix is a part of my
> interests.
>
> I do want to get CCed on general Guix Home topics, I'm ok with getting
> CCed on other guix home patches and threads outside of my
> interests/workload capabilities.
>
> If you think that confusion is severe, we can split the team into Guix
> Home Core and Guix Home Services, however I don't think it makes a lot
> of sence.
To me, team members commit to the best of their capacity to help with
patch review in the team’s scope. To receive notifications about a
given topic, I’d suggest using email filters or similar tools.
I hope that makes sense!
Ludo’.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-09-09 10:42 ` Andrew Tropin
2023-09-13 18:06 ` Ludovic Courtès
@ 2023-09-13 19:55 ` Ludovic Courtès
2023-09-17 7:01 ` Andrew Tropin
1 sibling, 1 reply; 25+ messages in thread
From: Ludovic Courtès @ 2023-09-13 19:55 UTC (permalink / raw)
To: Andrew Tropin; +Cc: 65119, 宋文武, paren
Andrew Tropin <andrew@trop.in> skribis:
> 1. One of the possible options is to use free-style configurations for
> services, so we can reuse a lot of code and drastically decrease
> duplication (only the service definition itself and a one configuration
> record) and maintanance burden.
We’ve had this discussion before; in the case of key/value-style
configuration, I’m against “free-style configuration” (nginx
configuration is a bit different).
With free-style configuration (I assume you have alists/sexps in mind),
you might end up generating invalid config files, or get obscure error
messages, or whatever; I’ve used Gnus for decades (!), any Gnus user
will know what I mean. This is Scheme, not Emacs Lisp/Common Lisp.
[...]
> 2. Another option is to rethink service extension mechanism a little bit
> and maybe make it more polymorphic.
> https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E
I very much support experimentation in this area; I’m sure there’s room
for improvement (like Julien’s extension points, which you referred to
in the message above).
I’m not sure how that relates to factorizing Home/System services though.
[...]
> My point here is: let's solve this issue on another level of
> abstraction, by improving service extension mechanism, not by creating a
> new level of abstraction (as we did in rde or in this patch series) to
> cover the wholes in the previous level.
Do you have ideas on how you’d change service extension to support
Home/System factorization?
> I would be glad to cooperate on this and design possible improvements.
I interpret this sentence as you suggesting that you’re outside the
project—even though my perception is that you’ve been part of it for
some time, even before you got commit rights. So do feel at Home!
(Pun intended. :-))
Ludo’.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-09-13 19:55 ` Ludovic Courtès
@ 2023-09-17 7:01 ` Andrew Tropin
2023-10-13 16:05 ` Ludovic Courtès
0 siblings, 1 reply; 25+ messages in thread
From: Andrew Tropin @ 2023-09-17 7:01 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 65119, 宋文武, paren
[-- Attachment #1: Type: text/plain, Size: 4184 bytes --]
On 2023-09-13 21:55, Ludovic Courtès wrote:
> Andrew Tropin <andrew@trop.in> skribis:
>
>> 1. One of the possible options is to use free-style configurations for
>> services, so we can reuse a lot of code and drastically decrease
>> duplication (only the service definition itself and a one configuration
>> record) and maintanance burden.
>
> We’ve had this discussion before; in the case of key/value-style
> configuration, I’m against “free-style configuration” (nginx
> configuration is a bit different).
>
> With free-style configuration (I assume you have alists/sexps in mind),
> you might end up generating invalid config files, or get obscure error
> messages, or whatever; I’ve used Gnus for decades (!), any Gnus user
> will know what I mean. This is Scheme, not Emacs Lisp/Common Lisp.
>
> [...]
>
>> 2. Another option is to rethink service extension mechanism a little bit
>> and maybe make it more polymorphic.
>> https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E
>
> I very much support experimentation in this area; I’m sure there’s room
> for improvement (like Julien’s extension points, which you referred to
> in the message above).
>
> I’m not sure how that relates to factorizing Home/System services though.
>
> [...]
>
>> My point here is: let's solve this issue on another level of
>> abstraction, by improving service extension mechanism, not by creating a
>> new level of abstraction (as we did in rde or in this patch series) to
>> cover the wholes in the previous level.
>
> Do you have ideas on how you’d change service extension to support
> Home/System factorization?
>
I'll write an example to demonstrate the high-level idea:
We have
--8<---------------cut here---------------start------------->8---
(extensions
(list (service-extension account-service-type
(const %dicod-accounts))
(service-extension shepherd-root-service-type
dicod-shepherd-service)))
--8<---------------cut here---------------end--------------->8---
We can do
--8<---------------cut here---------------start------------->8---
(home-environment
(services
(list (service dicod-service-type)))
(service-mapping
`((,shepherd-root-service-type . ,home-shepherd-service-type)
(,account-service-type . ,ignore-service-type))))
--8<---------------cut here---------------end--------------->8---
Now you can use the same service type and configuration record in
both operating-system and home-environment and use/ignore/interpret the
configuration fields values based on the environment we are building
this thing for.
Of course service-mapping default value can be generated upfront and
stored in %guix-home-service-mapping or something like that.
This way we will get rid of almost all home- services and related
configurations.
Keep in mind that it's a raw idea, not a well-designed solution yet.
>> I would be glad to cooperate on this and design possible improvements.
>
> I interpret this sentence as you suggesting that you’re outside the
> project—even though my perception is that you’ve been part of it for
> some time, even before you got commit rights. So do feel at Home!
> (Pun intended. :-))
My point was that rde home and system services are not affected much by
code duplication due to factorization through free-style serializers and
this problem is low priority for me at the moment. However in long term
the proper solution would be benefitial for both guix and rde.
The reason I'm suggesting to revert this patch series is because it
feels to me as a partial solution on the wrong level of abstraction,
which cures the symptoms and also introduces shortcomings and
potentially makes it harder to introduce a proper solution in the
future.
If this problem is urgent/demanding for you, please invite me for
working or collaborating on the solution explicitly, I plan work on it
anyway, but probably not earlier than the next year. I catched this
thread accidentially BTW, thanks to 宋文武 for CCing me.
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-09-17 7:01 ` Andrew Tropin
@ 2023-10-13 16:05 ` Ludovic Courtès
2023-10-14 6:03 ` Andrew Tropin
0 siblings, 1 reply; 25+ messages in thread
From: Ludovic Courtès @ 2023-10-13 16:05 UTC (permalink / raw)
To: Andrew Tropin; +Cc: 65119, 宋文武, paren
Hi Andrew,
Andrew Tropin <andrew@trop.in> skribis:
> We have
>
> (extensions
> (list (service-extension account-service-type
> (const %dicod-accounts))
> (service-extension shepherd-root-service-type
> dicod-shepherd-service)))
>
>
> We can do
>
> (home-environment
> (services
> (list (service dicod-service-type)))
> (service-mapping
> `((,shepherd-root-service-type . ,home-shepherd-service-type)
> (,account-service-type . ,ignore-service-type))))
As a user writing the ‘home-environment’ declaration, I don’t want to
know whether a Home service is implemented by mapping a System service
to Home, or whether it’s a fully separate implementation.
To me, users shouldn’t have to specify service mappings at all; service
mapping is a tool at the disposal of service writers.
> Now you can use the same service type and configuration record in
> both operating-system and home-environment and use/ignore/interpret the
> configuration fields values based on the environment we are building
> this thing for.
>
> Of course service-mapping default value can be generated upfront and
> stored in %guix-home-service-mapping or something like that.
>
> This way we will get rid of almost all home- services and related
> configurations.
>
> Keep in mind that it's a raw idea, not a well-designed solution yet.
The good thing is that we seem to agree on the general idea of having a
way to map System services to Home.
My take is that the mapping is an implementation detail that users do
not need to be aware of.
> The reason I'm suggesting to revert this patch series is because it
> feels to me as a partial solution on the wrong level of abstraction,
> which cures the symptoms and also introduces shortcomings and
> potentially makes it harder to introduce a proper solution in the
> future.
I disagree with this assessment.
> If this problem is urgent/demanding for you, please invite me for
> working or collaborating on the solution explicitly, I plan work on it
> anyway, but probably not earlier than the next year. I catched this
> thread accidentially BTW, thanks to 宋文武 for CCing me.
This problem has been discussed pretty much since Home was merged in
Guix¹; we’ve all had ample time to think about it and to my knowledge
this patch series is the only proposal that was ever brought.
I’ll close this bug for clarity. I remain open to discussion on the
implementation of System -> Home service mapping. I think further
discussion should happen in the context of incremental changes to the
implementation of that mapping mechanism, in a dedicated issue.
Thank you,
Ludo’.
¹ The cover letter at <https://issues.guix.gnu.org/65119> mentions two
services that would have been duplicated if we didn’t have this
mechanism.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [bug#65119] [PATCH 0/8] Sharing service code between Home and System
2023-10-13 16:05 ` Ludovic Courtès
@ 2023-10-14 6:03 ` Andrew Tropin
0 siblings, 0 replies; 25+ messages in thread
From: Andrew Tropin @ 2023-10-14 6:03 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 65119, 宋文武, paren
[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]
On 2023-10-13 18:05, Ludovic Courtès wrote:
> Hi Andrew,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> We have
>>
>> (extensions
>> (list (service-extension account-service-type
>> (const %dicod-accounts))
>> (service-extension shepherd-root-service-type
>> dicod-shepherd-service)))
>>
>>
>> We can do
>>
>> (home-environment
>> (services
>> (list (service dicod-service-type)))
>> (service-mapping
>> `((,shepherd-root-service-type . ,home-shepherd-service-type)
>> (,account-service-type . ,ignore-service-type))))
>
> As a user writing the ‘home-environment’ declaration, I don’t want to
> know whether a Home service is implemented by mapping a System service
> to Home, or whether it’s a fully separate implementation.
>
> To me, users shouldn’t have to specify service mappings at all; service
> mapping is a tool at the disposal of service writers.
>
>> Now you can use the same service type and configuration record in
>> both operating-system and home-environment and use/ignore/interpret the
>> configuration fields values based on the environment we are building
>> this thing for.
>>
>> Of course service-mapping default value can be generated upfront and
>> stored in %guix-home-service-mapping or something like that.
>>
>> This way we will get rid of almost all home- services and related
>> configurations.
>>
>> Keep in mind that it's a raw idea, not a well-designed solution yet.
>
> The good thing is that we seem to agree on the general idea of having a
> way to map System services to Home.
>
> My take is that the mapping is an implementation detail that users do
> not need to be aware of.
>
>> The reason I'm suggesting to revert this patch series is because it
>> feels to me as a partial solution on the wrong level of abstraction,
>> which cures the symptoms and also introduces shortcomings and
>> potentially makes it harder to introduce a proper solution in the
>> future.
>
> I disagree with this assessment.
>
>> If this problem is urgent/demanding for you, please invite me for
>> working or collaborating on the solution explicitly, I plan work on it
>> anyway, but probably not earlier than the next year. I catched this
>> thread accidentially BTW, thanks to 宋文武 for CCing me.
>
> This problem has been discussed pretty much since Home was merged in
> Guix¹; we’ve all had ample time to think about it and to my knowledge
> this patch series is the only proposal that was ever brought.
>
> I’ll close this bug for clarity. I remain open to discussion on the
> implementation of System -> Home service mapping. I think further
> discussion should happen in the context of incremental changes to the
> implementation of that mapping mechanism, in a dedicated issue.
👌
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread