[PATCH 0/8] Sharing service code between Home and System

  • Done
  • quality assurance status badge
Details
3 participants
  • Andrew Tropin
  • ???
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:04
(address . guix-patches@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
cover.1691355218.git.ludo@gnu.org
Hello Guix!

Some services make as much sense as a System and as a Home service.
Two examples that came up recently are Syncthing and dicod:


In these cases, we’d rather avoid code duplication and have a common
code base for both the System and the Home service.

This patch lets us map System services to Home and uses the new
mechanism for three services: mcron, dicod, and syncthing.

Feedback welcome!

Ludo’.

Ludovic Courtès (8):
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.

doc/guix.texi | 96 ++++++++++++++++++++++++++++++++-
gnu/home/services.scm | 69 +++++++++++++++++++++++-
gnu/home/services/dict.scm | 32 +++++++++++
gnu/home/services/mcron.scm | 96 ++++-----------------------------
gnu/home/services/shepherd.scm | 4 +-
gnu/home/services/syncthing.scm | 30 +++++++++++
gnu/local.mk | 2 +
gnu/services.scm | 25 ++++++++-
gnu/services/dict.scm | 84 ++++++++++++++---------------
gnu/services/mcron.scm | 80 ++++++++++++---------------
gnu/services/syncthing.scm | 56 ++++++++++---------
11 files changed, 372 insertions(+), 202 deletions(-)
create mode 100644 gnu/home/services/dict.scm
create mode 100644 gnu/home/services/syncthing.scm


base-commit: 0ab46ef3f9719f03d9b191a16e5aa91619e95451
--
2.41.0
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 1/8] services: dicod: Remove Shepherd < 0.9.0 compatibility layer.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
5301257cba680ba2d4ab7115c1712090276a1f46.1691355218.git.ludo@gnu.org
* 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(-)

Toggle diff (44 lines)
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
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 2/8] services: dicod: Pre-build the GCIDE index.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
e885dd784b857cf88c5bed519e91d3856248b805.1691355218.git.ludo@gnu.org
* 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(-)

Toggle diff (67 lines)
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
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 3/8] services: syncthing: Use 'match-record'.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
c9d4ff85ef4a02899d8e8fa2c952d1d3d0dd16ee.1691355218.git.ludo@gnu.org
* 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(-)

Toggle diff (65 lines)
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
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 4/8] services: Define 'for-home'.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
55a8ef59696bd6f80da9e1bc5f8ca940df11eda6.1691355218.git.ludo@gnu.org
* 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(-)

Toggle diff (48 lines)
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
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 5/8] home: services: Support mapping of System services to Home services.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
2e33f4ce62f4238a147e1bac16302751efe69c26.1691355218.git.ludo@gnu.org
* 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(-)

Toggle diff (120 lines)
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.")))
+
+;;;
+;;; 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))
+
;;;
;;; 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
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 6/8] home: services: mcron: Define as a mapping of the system service.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
319a7664fdf2b910f4183ce3c748234a8763e107.1691355218.git.ludo@gnu.org
* 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(-)

Toggle diff (269 lines)
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)))))
-
-;;;
-;;; 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
-
-;;;
-;;; Generate documentation.
-;;;
-(define (generate-doc)
- (configuration->documentation 'mcron-configuration))
-
;;; mcron.scm ends here
--
2.41.0
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 7/8] home: services: Add dicod.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
bdcd223fd6768fb4fe91f11912ae009e2b5dcd32.1691355218.git.ludo@gnu.org
* 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

Toggle diff (188 lines)
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
L
L
Ludovic Courtès wrote on 6 Aug 2023 23:07
[PATCH 8/8] home: services: Add Syncthing.
(address . 65119@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
cd291ee2ab9237a253a67b10d155a736404dcc30.1691355218.git.ludo@gnu.org
* 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

Toggle diff (201 lines)
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
?
?
??? wrote on 13 Aug 2023 07:28
Re: bug#65119: [PATCH 0/8] Sharing service code between Home and System
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ttt3a4tm.fsf@envs.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (14 lines)
> [...]
>
> 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!
L
L
Ludovic Courtès wrote on 20 Aug 2023 23:23
(name . ???)(address . iyzsong@envs.net)
87h6otpfwa.fsf_-_@gnu.org
Hi,

??? <iyzsong@envs.net> skribis:

Toggle quote (18 lines)
> 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’.
Closed
A
A
Andrew Tropin wrote on 21 Aug 2023 15:43
87r0nwh5om.fsf@trop.in
On 2023-08-13 13:28, ??? wrote:

Toggle quote (18 lines)
> 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:

Toggle snippet (4 lines)
(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.

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.

--
Best regards,
Andrew Tropin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmTjafkACgkQIgjSCVjB
3rBuEBAAhRuAXkJen8aGjulp58QZFqBnYjrYRFuSC//q0jsaKepGcsNA3XF+qx1l
9/GmN25g7McIkwuMWIqWJY30RMp938637ki1uBNo4zFZBSQKKyPG+LKdNk84kCQk
En8TLd0r1xzt3u7Jn6BpJ41Ulx3RSxZwmhuV1Zn2E4aENkbC5IA4/m1raB6hUsy+
zsTRcrvhx13/8V4ZBLu+U6nMi9Y/8FeCXzRJkg8I2ye06zzQAvwwii5fgKfmj6/G
B0g/3r21lfUREbs7xikJDluWs4HCCrIayT4B9bB3C2VUaNObVQoUjRqhapHkUFvi
RmHSEfPMk7mPCE2M2sgpHOsUcLT3mgwqoF9Q72nr22qf6uDwA483f2ksKR1O6Ul9
Z2z6kE/r86Y1BbCd1rVJohcretu5wDYbQoWVPATHZoCCBath/4BCqvWqqLCOEm/X
dF8bv3vuv3wCbfK8DxY7G4CeymlJivCBcp275s74DTkdKUqEPthSe3pddEXJfI1z
jEmXjRaIu/kfiGgSDy7AtL4pQESl9StABtnzNFIoVOTLvS+ckZV/KEkrfOS0N7kf
ej+PsPhCc/3q0Q5KwrjuMj46kv+/8+FXwHbW5rR6RLiKDKuLn7qYySFukF6UJ871
qqDMGU5401Rpf7a/QLhE8fohpL6eiWDv9nwXqbyg20+cCWfyeV8=
=Xiui
-----END PGP SIGNATURE-----

A
A
Andrew Tropin wrote on 21 Aug 2023 17:50
Re: [bug#65119] [PATCH 6/8] home: services: mcron: Define as a mapping of the system service.
87o7j0gzsw.fsf@trop.in
On 2023-08-06 23:07, Ludovic Courtès wrote:

Toggle quote (204 lines)
> * 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)))))
>
> -
> -;;;
> -;;; 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.

Toggle quote (86 lines)
> + "/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
>
> -
> -;;;
> -;;; Generate documentation.
> -;;;
> -(define (generate-doc)
> - (configuration->documentation 'mcron-configuration))
> -
> ;;; mcron.scm ends here

--
Best regards,
Andrew Tropin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmTjh78ACgkQIgjSCVjB
3rAaMg/+PIW0DJ5NyaJtIUZzCT+YaAaTdE0ZQ8pRbuSqZLZb/zQXdGYgb2wRPKvL
vpL16XYqiJgj4irXkJLORPp9dNvaUlNjNHToBN4CHOSs17+UUGFa988WxYIc8OA/
v/4p9FwSoW4e8O7lCVj5OQUh03N3AVJrMvyumDuGt/d+lgZUBxKe6R5E5OYa5wF6
vu1C5bgCRB0b46m0nVWtrX2devGAQYTSo1k52BCAnD6ffWLam91hXVKVYkWppckr
dDweIlzE+qx3CE7cAF8TpfIGge0A8aj+AzyiHkSJDuWrSQkMtPGyYENPJZzELr0s
swollJEdJ4/8WbfAh9kt+2UCY0uYeCT9h31kULV+j4j0WiWo0pXTwoPLi+BMrmxI
o1XwicRHgovP+LuhvaV7YpPCyYR5GocRt/8VMrEW9xDrUOTm44BrcKODU+CmYiIF
pCVUndhGcj4jeggA5nO5gfBZHIw8b8G/2kyuN9wDu1kMZh/Ua7qqGcfz/K8oFZrC
3f647oAfFNZ3O9QSOrIFe3k4EtrSwoSNJj3TxjcJ11dgyln9/zWzH8m4k7t2aCTq
rv5kqBwvsJ2XX/xcGIR/18AUKiDcozeKm/kzytUFaEJefrFp31cK7FQ0ADlgfU54
9LUr9uXD5iaRxBSBq4p1/gKzg/Bra9sbUwYO189U5PBnuq9PEZ8=
=eEtZ
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 22 Aug 2023 18:25
Re: bug#65119: [PATCH 0/8] Sharing service code between Home and System
(name . Andrew Tropin)(address . andrew@trop.in)
87jztn3uz1.fsf@gnu.org
Hi Andrew,

Andrew Tropin <andrew@trop.in> skribis:

Toggle quote (19 lines)
> 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?

Toggle quote (12 lines)
> 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’.
A
A
Andrew Tropin wrote on 25 Aug 2023 08:28
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ttsnoct1.fsf@trop.in
On 2023-08-22 18:25, Ludovic Courtès wrote:

Toggle quote (27 lines)
> 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.

Toggle quote (31 lines)
>
> 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.

Toggle quote (12 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmToSioACgkQIgjSCVjB
3rDAnw/+MfkFcHw/XcTyD20CxMWnibpV/l2hWvFkvsMyvZ0cBfbR4Z5JXYJFsmZp
Etj9PjEUGIMfDmL5h3QXnMKss20eW7/reTqj1h0JvWdRbjkCtNBp0xGwwe2SV3TF
OsLIiy3ww8oALvsaF4n1FkBOqwjgQsh1IQKlqqIfIfI5Xzb103nIGKJYROnqnKe7
zyd4l8KgQXQYNvucoQ3bVtWSZ8/Oc3VfiMpdfHx7dpcD1RajvmzNrFOQ881/Nxmj
gu61diI7zN21MkceaK52yvJ30s23tZ6Em11C8/i8ziqsDMIAIDRYQG47fgAx5tXC
sW644guJqxM01CYI4KY/99IGQAblDU9C77LxnkOGP+7vq35AF/NHUuUpJyBP76GU
icXsKoDK1QJhj/qDoQlYDR6cY0jkM0WqpUIMnwH5P8MVcowRtt1uq6F1umeELdMc
ZBlx38fbGP5MKuloVPEhpF5sqVPRiw7Ym3GMwL/oH5ZwkFikPRucTjN9uqkYMO5F
ujlGYncUTXYcw4OetSdLNX74tI5M31DL7NaraQxOUz3GtRkk7/zZ9jgUO5V4Rghs
NZ3st9YNOhECyBw4SgOSF4iBJNi4BoUwVKPBRjcB74Jy4ZMMo0fOXGL1NfH25Vb+
n9o19bhFjm7F11F+pg+9A1y02OKffCGYZYPILTV1viT1erJY1zw=
=wC/3
-----END PGP SIGNATURE-----

A
A
Andrew Tropin wrote on 8 Sep 2023 14:42
(name . Ludovic Courtès)(address . ludo@gnu.org)
87bkec6dkn.fsf@trop.in
On 2023-08-25 10:28, Andrew Tropin wrote:

Toggle quote (38 lines)
> 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:


It highlights this:

Toggle quote (5 lines)
> 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.

Toggle quote (70 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmT7FsgACgkQIgjSCVjB
3rCkfA//aS+LyB4R5/jKJSXqPRm4HHRJC/zBbDT5cPowyLRX2ymVQZoYwqCIeDxx
4NnVOYLrjjTe7UwOg+QIcMDpyhFNcOIJt8UvyI5NCpkwLyzHx7+2lvJq9WBuBM0y
qDfOkWCoI8ywPrDpz+ajjUoYxE/cmg3IjhECmU/RacHqzGFZry6EG0PD6txpX7Yi
l/sdaISnvVkLllvvaZGASgNQ7huwmLpNGCW0hNDzu2+GdVM0LI2kJCyAQG+PvXu8
avRQI0pfvvOdIeps70b4pv34yxylBA+ZuxphGmk8lUmWI5vRWHBF3WCcw3v6hnCc
T3pqRofxXNgrHhyaEqQ3VPCNXT04bfN4hl2vJmyX+M8E+7Zq9My+BQh0sHZVK2JE
Ui/Mtx5vzmSPxFqjwbgG5UfJfpWA9zuJIpikDHVf4sYVkhQOrK0o9cRULg9ppAuE
aVc21kyRvA3gDBnEWrp754rY7dJ4JNzWHNVrbxKgx/O4rV0HChGpxjyLkBwI6r5C
HMbDuRqI5jns2MmGwGrRbbFDuNkX6hDSFLDQPi7/AXJoipJ8sIVR06wT01nl9eCM
ZDGE13hS9obZCNmyDIdKh0bbeFVsWMccMgpuiqVzlg1+RR7k6oiBs/E1uiULUZn8
BUn7xLfwdxvpcfUbHbF93jIJ7I6XEMW41cJMDvYVJj+1TOHqRJI=
=i2uj
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 9 Sep 2023 00:18
(name . Andrew Tropin)(address . andrew@trop.in)
87wmx0z4u4.fsf@gnu.org
Hi Andrew,

Andrew Tropin <andrew@trop.in> skribis:

Toggle quote (25 lines)
> 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:


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’.
A
A
Andrew Tropin wrote on 9 Sep 2023 12:42
(name . Ludovic Courtès)(address . ludo@gnu.org)
874jk3sk57.fsf@trop.in
On 2023-09-09 00:18, Ludovic Courtès wrote:

Toggle quote (46 lines)
> 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.

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.

(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.

Toggle quote (6 lines)
> 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
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.

Toggle quote (5 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmT8TAQACgkQIgjSCVjB
3rCCPBAAlrSdaKKr5Y8jRpnUAjbg280odXuHJ9gnBa+fPLx+SzWo+U3JoHSyoIm+
yOg8Ej5+yMxqXtOonCU2eRXwdIuKFq3qhztvbyo9eJWh7ioQju/sh6HFIV4rlAeo
JIaCvqjZFmvPxRKJXdsoAAn9UXn+0/GES483ymJGNKUDR1jbXA/r//RTpQU60VgI
N07OTY25fhzj8W4NI5PoxMSbZ+Y2aHYSH6Bf88J+uUaer/tF611C1yKvzez5aeub
qXZQmCnEcn7CJzNUlowTVMhC5/mVNlg0PwBR0FNeZtKEm/8w+PHQYaIk+6/DkmxQ
HobpWujGADaH7+OdgsWheAQ/RQRwDshvHZNf6vx+x62+PsAhmH8V8CCK/MAfUfc5
FzGA/A81X97cKMxd8Y1MBIcOOx1LrVt0Yl5ILDSC7tfgbah4wvy6lM3P9StDxA3Z
yUUT7noIVpek8jwoPDl48eAIbTH0AI5I40ZI2j0ze3QjPmNWf/qEdZ2Fb+bVjCBy
vMx+oVSnaqsBO3W10T3kNy3vk5Oc64d7ivD6rZduCV9M/C9XlJu9uE03OosT9gD3
W1kTFuSE4KvVKGm3Gu08pdrFILusIfoMjEPPdYch9XEIVDD5KaFbirpMi0y3ofyZ
na9SgMIba2kstjzYJaTnvZKg7UMXcUQrYU/0vIEXu//kCUyJbAM=
=xb1u
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 13 Sep 2023 20:06
(name . Andrew Tropin)(address . andrew@trop.in)
878r9alzh9.fsf@gnu.org
Hi,

Andrew Tropin <andrew@trop.in> skribis:

Toggle quote (10 lines)
> 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’.
L
L
Ludovic Courtès wrote on 13 Sep 2023 21:55
(name . Andrew Tropin)(address . andrew@trop.in)
87led9lufr.fsf@gnu.org
Andrew Tropin <andrew@trop.in> skribis:

Toggle quote (5 lines)
> 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.

[...]

Toggle quote (4 lines)
> 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.

[...]

Toggle quote (5 lines)
> 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?

Toggle quote (2 lines)
> 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’.
A
A
Andrew Tropin wrote on 17 Sep 2023 07:28
(name . Ludovic Courtès)(address . ludo@gnu.org)
87wmwpxtaa.fsf@trop.in
On 2023-09-13 20:06, Ludovic Courtès wrote:

Toggle quote (16 lines)
> 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.

Toggle quote (4 lines)
> 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:
Toggle snippet (14 lines)
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.

--
Best regards,
Andrew Tropin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmUGjn0ACgkQIgjSCVjB
3rCwug/8DWGUTUE+I/0X/PoWJyKN6K0MQi8uVsC+Wj/MBRb2ZI0EUJBQGkOZJ1Gj
EA9LowQVlDNuf3URPT9Bm8YoPgp8MoVUX/F1Icd4qL+sRYT/Z7Fyc/lk07oOqkwE
teu4KWfKHmO7Pu8cdQcD7+ZyE0WpPr6XSgufmitsJESPpvYZMi4M6qXc0UXAn+0M
ed5I5l69InSPzixY2fKg7Y0tltVct5nkID10/RYDJPM9T8ANiOqIE9URbAi2ARpy
6TpZyun7CH+buMizsP8fUxPWYYHiTXHBM5lyP48H7f0tSjWh9Fyd+3dmk9pal4Q4
XrFjMGovURJB5r9UyYUFzWUTwf2M4lxRs2Iz0i01rc23eGLmkueDipgE1BNwbbcl
HtyO6z9geLGDFeK7vVbyqC5HkH8lVWDj2Ktj29rgn/MBMGuWEP9Fj7RLztJn75cq
sPFywc3rzJqpxFsZ/K+IaRvq5I0If5V8jHPOcOcz/Lihjjchj0VH/Hb8vBuACL88
1Kg3fsXLI2cW7x9Az4aCZkvH+UZTXNVa/dMJLNoR6G/MC52yyu4eluRHMisrrjsk
Yqk8RTdMzh+mcBh7dU4DLOTwZTwSfAwuqr0sboKyjoWCjCgLM80Kha6t84bTYNu5
5lJHJs77CQnx4+CkgUAYqiBPnGUoxMn2dQkPddK6Cw1u0s2NmmY=
=+ngO
-----END PGP SIGNATURE-----

A
A
Andrew Tropin wrote on 17 Sep 2023 09:01
(name . Ludovic Courtès)(address . ludo@gnu.org)
87msxlxozr.fsf@trop.in
On 2023-09-13 21:55, Ludovic Courtès wrote:

Toggle quote (39 lines)
> 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
Toggle snippet (7 lines)
(extensions
(list (service-extension account-service-type
(const %dicod-accounts))
(service-extension shepherd-root-service-type
dicod-shepherd-service)))

We can do
Toggle snippet (8 lines)
(home-environment
(services
(list (service dicod-service-type)))
(service-mapping
`((,shepherd-root-service-type . ,home-shepherd-service-type)
(,account-service-type . ,ignore-service-type))))

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.

Toggle quote (7 lines)
>> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmUGpDgACgkQIgjSCVjB
3rBi3A//W2L5/mk67cXgCfnk9tgCPtPuhZIH+FBx2EwKG9Bncq/d6cgkTKt2x/Ye
67YBY+oacunl6ND2OIoEUyk5JQsiAmLIaefFVRNPCKYr8cAnxDnVM8oPL20flMcK
b8rhi1uVFWyjUpp5WhaXwj+yTr2qxbSTNww5rDhLsoQVQNgVcJCvgUn2Deyx/PsJ
U+Sam32hs1WK+YroWaok+80RcCGJvjavg5mY4k8eNBzl+Cytqazc01116nRf9J7v
LHwDPJvVnUZGvbsBGmMTAQOu/Dy1fGDKEvogfAYBoNJT+U5goY+DJTcMgZXVZkes
e0V6t5KsYkNJS4vkuSBuJDFtaONQsM7Fbd3ZoacEfa028Uq/dCvP0arMyJ/iyiHf
E93fcQUBNYCV2LJxJHAMfoP3/Zm0Yw2COMcrLsckrCsfgnsNYagPSfqp1+k/q+AJ
KnU3AduoGTAl92lXAUA5OdA6WkyJAjV31Ugp2AG4oK8uTduIip+RMMsIVNYELjqE
iyshDeBsqWVieDhpzjceSz0I1PoH9bF+HxcPDppqsq50eTvYn9H0SAPbgpPUab/T
NYvhH/g6SL1sPO4BO09lubby/P7bvGsdb6u4G6l/Ssm8RasMH/NA/dfjUQAvRm32
PRrWD8/SfESAcsbUqGATr8+A7pixZ1LCA5Uz4Asd55lDasp2r/Y=
=TXaR
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 17 Sep 2023 12:27
(name . Andrew Tropin)(address . andrew@trop.in)
874jjtyu0z.fsf@gnu.org
Hi

Andrew Tropin <andrew@trop.in> skribis:

Toggle quote (9 lines)
> 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

[...]

Toggle quote (4 lines)
>> 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.

[...]

Toggle quote (27 lines)
>> 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’.
L
L
Ludovic Courtès wrote on 13 Oct 2023 18:05
Re: [bug#65119] [PATCH 0/8] Sharing service code between Home and System
(name . Andrew Tropin)(address . andrew@trop.in)
87a5smik3p.fsf@gnu.org
Hi Andrew,

Andrew Tropin <andrew@trop.in> skribis:

Toggle quote (18 lines)
> 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.

Toggle quote (13 lines)
> 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.

Toggle quote (6 lines)
> 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.

Toggle quote (5 lines)
> 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.
L
L
Ludovic Courtès wrote on 13 Oct 2023 18:05
control message for bug #65119
(address . control@debbugs.gnu.org)
878r86ik3e.fsf@gnu.org
close 65119
quit
A
A
Andrew Tropin wrote on 14 Oct 2023 08:03
Re: [bug#65119] [PATCH 0/8] Sharing service code between Home and System
(name . Ludovic Courtès)(address . ludo@gnu.org)
87zg0llp0c.fsf@trop.in
On 2023-10-13 18:05, Ludovic Courtès wrote:

Toggle quote (70 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmUqLyMACgkQIgjSCVjB
3rBCIA/6A3SDh1dqwY/irFNntNwKFVCtBA2OR0bgvVFGWwPFFmQdvTG1IubAQyfB
7OYqVEuUiw/jhf2EZOJ3xXtEurzHok6Sj2rayB58b7c04jD7YXdvqQP3cpRA6ftw
4Lhxe/R598mQ55Z1iPYmvbjnN03mZTJKDg8mi2v+eCOi1V1nHOqEF6S5B9KMNPKU
McA+vDtPXL+wSgUh/sS1VRjjRMyiSOIBgp2KcR3jUg0pXaEF4vrw+TijFf9sH3Cg
aWUpR7PYAUDjXKF3ig/9c1pKGeLJcUPd/rYjGoSErInkZJ4ZvQjMHX5yjGg8eHbb
38ckIwr3r02wSRytkwC1xkeOqZbBKnSnwdL5UYGwNA+jQ8FaLmA3lCYZVPhQlu1Y
0Ef+WSNVxMV2wHpwqUtmNz8WsdihLHC7dsU0wZhbf62jXHAN6XZkqNHmKZ/tLgn9
oVp6feYE8OjELrKM+DGD9nywf8c8D0DRZRlFWRmCw3u2J9rZwXzLdmb6WxjxJLgf
CWPgBLW63366hffoeFMnRmmVlKNdNE4NH0ld9BzK9jboEl76Pghm68uuPI92zBi7
lvsDSLGCRAXPexgBExXiD+Uq8Kqj+JHbs8YL3u+1N+00dK66qlCPU6KDGegsw9pK
ew8okJ9nlL6MjqvULwAM5rSwves6xel+NdW4+U8YorZI13623b8=
=B4uv
-----END PGP SIGNATURE-----

?
Your comment

This issue is archived.

To comment on this conversation send an email to 65119@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 65119
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch