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