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

> [...]

>

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

> Ludovic Courtès <ludo@gnu.org> writes:

>

>> [...]

>>

>> This patch lets us map System services to Home and uses the new

>> mechanism for three services: mcron, dicod, and syncthing.

>>

>> services: dicod: Remove Shepherd < 0.9.0 compatibility layer.

>> services: dicod: Pre-build the GCIDE index.

>> services: syncthing: Use 'match-record'.

>> services: Define 'for-home'.

>> home: services: Support mapping of System services to Home services.

>> home: services: mcron: Define as a mapping of the system service.

>> home: services: Add dicod.

>> home: services: Add Syncthing.

>

> I didn't test them, but those changes look good to me!

> Ludovic Courtès <ludo@gnu.org> writes:

>

>> [...]

>>

>> This patch lets us map System services to Home and uses the new

>> mechanism for three services: mcron, dicod, and syncthing.

>>

>> services: dicod: Remove Shepherd < 0.9.0 compatibility layer.

>> services: dicod: Pre-build the GCIDE index.

>> services: syncthing: Use 'match-record'.

>> services: Define 'for-home'.

>> home: services: Support mapping of System services to Home services.

>> home: services: mcron: Define as a mapping of the system service.

>> home: services: Add dicod.

>> home: services: Add Syncthing.

>

> I didn't test them, but those changes look good to me!

> * gnu/services/mcron.scm (list-of-gexps?): Remove.

> (<mcron-configuration>): Rewrite using 'define-record-type*'.

> [home-service?]: New field.

> [log-file]: Make thunked and changed default value.

> (mcron-shepherd-services): Honor 'home-service?' and remove use of

> 'maybe-value-set?'.

> (mcron-service-type): Inherit 'home-service?' from CONFIG.

> (generate-doc): Remove.

> * gnu/home/services/mcron.scm (list-of-gexp?)

> (<home-mcron-configuration>, job-files, shepherd-schedule-action)

> (home-mcron-shepherd-services, home-mcron-profile)

> (home-mcron-extend, generate-doc): Remove.

> (home-mcron-configuration): Turn into a macro.

> (home-mcron-service-type): Define in terms of

> 'system->home-service-type'.

> <top level>: Add service type mapping.

> ---

> gnu/home/services/mcron.scm | 96 ++++---------------------------------

> gnu/services/mcron.scm | 80 ++++++++++++++-----------------

> 2 files changed, 45 insertions(+), 131 deletions(-)

>

> diff --git a/gnu/home/services/mcron.scm b/gnu/home/services/mcron.scm

> index f51edd6634..23be44ba07 100644

> --- a/gnu/home/services/mcron.scm

> +++ b/gnu/home/services/mcron.scm

> @@ -2,6 +2,7 @@

> ;;; Copyright © 2021, 2023 Andrew Tropin <andrew@trop.in>

> ;;; Copyright © 2021 Xinglu Chen <public@yoctocell.xyz>

> ;;; Copyright © 2022 Maxim Cournoyer <maxim.cournoyer@gmail.com>

> +;;; Copyright © 2023 Ludovic Courtès <ludo@gnu.org>

> ;;;

> ;;; This file is part of GNU Guix.

> ;;;

> @@ -19,16 +20,9 @@

> ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.

>

> (define-module (gnu home services mcron)

> - #:use-module (gnu packages guile-xyz)

> #:use-module (gnu home services)

> - #:use-module (gnu services configuration)

> - #:use-module (gnu services shepherd)

> #:use-module (gnu home services shepherd)

> - #:use-module (guix records)

> - #:use-module (guix gexp)

> - #:use-module (srfi srfi-1)

> - #:use-module (ice-9 match)

> -

> + #:use-module (gnu services mcron) ;for the service mapping

> #:export (home-mcron-configuration

> home-mcron-service-type))

>

> @@ -55,86 +49,16 @@ (define-module (gnu home services mcron)

> ;;

> ;;; Code:

>

> -(define list-of-gexps?

> - (list-of gexp?))

> -

> -(define-configuration/no-serialization home-mcron-configuration

> - (mcron (file-like mcron) "The mcron package to use.")

> - (jobs

> - (list-of-gexps '())

> - "This is a list of gexps (@pxref{G-Expressions}), where each gexp

> -corresponds to an mcron job specification (@pxref{Syntax, mcron job

> -specifications,, mcron, GNU@tie{}mcron}).")

> - (log? (boolean #t) "Log messages to standard output.")

> - (log-format

> - (string "~1@*~a ~a: ~a~%")

> - "@code{(ice-9 format)} format string for log messages. The default value

> -produces messages like \"@samp{@var{pid} @var{name}:

> -@var{message}\"} (@pxref{Invoking mcron, Invoking,, mcron, GNU@tie{}mcron}).

> -Each message is also prefixed by a timestamp by GNU Shepherd."))

> -

> -(define job-files (@@ (gnu services mcron) job-files))

> -(define shepherd-schedule-action

> - (@@ (gnu services mcron) shepherd-schedule-action))

> -

> -(define (home-mcron-shepherd-services config)

> - (match-record config <home-mcron-configuration>

> - (mcron jobs log? log-format)

> - (if (null? jobs)

> - '() ;no jobs to run

> - (let ((files (job-files mcron jobs)))

> - (list (shepherd-service

> - (documentation "User cron jobs.")

> - (provision '(mcron))

> - (modules `((srfi srfi-1)

> - (srfi srfi-26)

> - (ice-9 popen) ;for the 'schedule' action

> - (ice-9 rdelim)

> - (ice-9 match)

> - ,@%default-modules))

> - (start #~(make-forkexec-constructor

> - (list (string-append #$mcron "/bin/mcron")

> - #$@(if log?

> - #~("--log" "--log-format" #$log-format)

> - #~())

> - #$@files)

> - #:log-file (string-append

> - (or (getenv "XDG_STATE_HOME")

> - (format #f "~a/.local/state"

> - (getenv "HOME")))

> - "/log/mcron.log")))

> - (stop #~(make-kill-destructor))

> - (actions

> - (list (shepherd-schedule-action mcron files)))))))))

> -

> -(define home-mcron-profile (compose list home-mcron-configuration-mcron))

> -

> -(define (home-mcron-extend config jobs)

> - (home-mcron-configuration

> - (inherit config)

> - (jobs (append (home-mcron-configuration-jobs config)

> - jobs))))

> +(define-syntax-rule (home-mcron-configuration fields ...)

> + ;; Macro provided for backward compatibility.

> + (for-home (mcron-configuration fields ...)))

>

> (define home-mcron-service-type

> - (service-type (name 'home-mcron)

> - (extensions

> - (list (service-extension

> - home-shepherd-service-type

> - home-mcron-shepherd-services)

> - (service-extension

> - home-profile-service-type

> - home-mcron-profile)))

> - (compose concatenate)

> - (extend home-mcron-extend)

> - (default-value (home-mcron-configuration))

> - (description

> - "Install and configure the GNU mcron cron job manager.")))

> + (service-type

> + (inherit (system->home-service-type mcron-service-type))

> + (default-value (for-home (mcron-configuration)))))

>

> -

> -;;;

> -;;; Generate documentation.

> -;;;

> -(define (generate-doc)

> - (configuration->documentation 'home-mcron-configuration))

> +(define-service-type-mapping

> + mcron-service-type => home-mcron-service-type)

>

> ;;; mcron.scm ends here

> diff --git a/gnu/services/mcron.scm b/gnu/services/mcron.scm

> index 2ef5980e09..db8b539ff5 100644

> --- a/gnu/services/mcron.scm

> +++ b/gnu/services/mcron.scm

> @@ -1,5 +1,5 @@

> ;;; GNU Guix --- Functional package management for GNU

> -;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>

> +;;; Copyright © 2016-2020, 2023 Ludovic Courtès <ludo@gnu.org>

> ;;; Copyright © 2022 Maxim Cournoyer <maxim.cournoyer@gmail.com>

> ;;; Copyright © 2023 Bruno Victal <mirai@makinata.eu>

> ;;;

> @@ -20,10 +20,8 @@

>

> (define-module (gnu services mcron)

> #:use-module (gnu services)

> - #:use-module (gnu services configuration)

> #:use-module (gnu services shepherd)

> #:use-module (gnu packages guile-xyz)

> - #:use-module (guix deprecation)

> #:use-module (guix records)

> #:use-module (guix gexp)

> #:use-module (srfi srfi-1)

> @@ -37,6 +35,7 @@ (define-module (gnu services mcron)

> mcron-configuration-log-file

> mcron-configuration-log-format

> mcron-configuration-date-format

> + mcron-configuration-home-service?

>

> mcron-service-type))

>

> @@ -55,40 +54,34 @@ (define-module (gnu services mcron)

> ;;;

> ;;; Code:

>

> -(define list-of-gexps?

> - (list-of gexp?))

> +;; Configuration of mcron.

> +;; XXX: 'define-configuration' cannot be used here due to the need for

> +;; 'thunked' and 'innate' fields as well as 'this-mcron-configuration'.

> +(define-record-type* <mcron-configuration> mcron-configuration

> + make-mcron-configuration

> + mcron-configuration?

> + this-mcron-configuration

>

> -(define-maybe/no-serialization string)

> + (mcron mcron-configuration-mcron ;file-like

> + (default mcron))

> + (jobs mcron-configuration-jobs ;list of gexps

> + (default '()))

> + (log? mcron-configuration-log? ;Boolean

> + (default #t))

> + (log-file mcron-configuration-log-file ;string | gexp

> + (thunked)

> + (default

> + (if (mcron-configuration-home-service?

> + this-mcron-configuration)

> + #~(string-append %user-log-dir "/mcron.log")

> + "/var/log/mcron.log")))

> + (log-format mcron-configuration-log-format ;string

> + (default "~1@*~a ~a: ~a~%"))

> + (date-format mcron-configuration-date-format ;string | #f

> + (default #f))

>

> -(define-configuration/no-serialization mcron-configuration

> - (mcron

> - (file-like mcron)

> - "The mcron package to use.")

> -

> - (jobs

> - (list-of-gexps '())

> - "This is a list of gexps (@pxref{G-Expressions}), where each gexp

> -corresponds to an mcron job specification (@pxref{Syntax, mcron job

> -specifications,, mcron, GNU@tie{}mcron}).")

> -

> - (log?

> - (boolean #t)

> - "Log messages to standard output.")

> -

> - (log-file

> - (string "/var/log/mcron.log")

> - "Log file location.")

> -

> - (log-format

> - (string "~1@*~a ~a: ~a~%")

> - "@code{(ice-9 format)} format string for log messages. The default value

> -produces messages like @samp{@var{pid} @var{name}: @var{message}}

> -(@pxref{Invoking mcron, Invoking,, mcron, GNU@tie{}mcron}).

> -Each message is also prefixed by a timestamp by GNU Shepherd.")

> -

> - (date-format

> - maybe-string

> - "@code{(srfi srfi-19)} format string for date."))

> + (home-service? mcron-configuration-home-service?

> + (default for-home?) (innate)))

>

> (define (job-files mcron jobs)

> "Return a list of file-like object for JOBS, a list of gexps."

> @@ -158,13 +151,15 @@ (define (shepherd-schedule-action mcron files)

>

> (define (mcron-shepherd-services config)

> (match-record config <mcron-configuration>

> - (mcron jobs log? log-file log-format date-format)

> + (mcron jobs log? log-file log-format date-format home-service?)

> (if (eq? jobs '())

> '() ;nothing to do

> (let ((files (job-files mcron jobs)))

> (list (shepherd-service

> (provision '(mcron))

> - (requirement '(user-processes))

> + (requirement (if home-service?

> + '()

> + '(user-processes)))

> (modules `((srfi srfi-1)

> (srfi srfi-26)

> (ice-9 popen) ;for the 'schedule' action

> @@ -175,7 +170,7 @@ (define (mcron-shepherd-services config)

> (list #$(file-append mcron "/bin/mcron")

> #$@(if log?

> `("--log" "--log-format" ,log-format

> - ,@(if (maybe-value-set? date-format)

> + ,@(if date-format

> (list "--date-format"

> date-format)

> '()))

> @@ -209,15 +204,10 @@ (define mcron-service-type

> (extend (lambda (config jobs)

> (mcron-configuration

> (inherit config)

> + (home-service?

> + (mcron-configuration-home-service? config))

> (jobs (append (mcron-configuration-jobs config)

> jobs)))))

> (default-value (mcron-configuration)))) ;empty job list

>

> -

> -;;;

> -;;; Generate documentation.

> -;;;

> -(define (generate-doc)

> - (configuration->documentation 'mcron-configuration))

> -

> ;;; mcron.scm ends here

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

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

> Hi Andrew,

>

> Andrew Tropin <andrew@trop.in> skribis:

>

>> Sorry for comming late to the party, I saw this message only a week ago

>> and didn't have time to make an extensive reply yet, so I will share my

>> quick thought on the most problematic part and maybe later will

>> formulate others thoughts in more details.

>>

>> define-service-type-mapping looks imperative and potentially very

>> problematic. Collecting those values in unknown order and applying this

>> implicit transformation making a good room for foot shooting. Imagine

>> someone would like to use his own (let's say) shepherd home service

>> implementation and will add this to one of the source files of their

>> channel:

>>

>> (define-service-type-mapping

>> shepherd-root-service-type => my-home-shepherd-service-type)

>>

>> What happens if somebody will use his channel just for getting some

>> package? Very likely it would break the build or in the worst case it

>> will build with unexpected service implementation under the hood.

>

> Yes, this is always possible. Though it’s not very different from:

>

> (set! home-shepherd-service-type …)

>

> Maybe the unintended effect is more likely to happen unwillingly though,

> maybe.

>

> Do you have other solutions in mind, be it for this specific issue or

> for system/home service mapping in general?

>

>> I had [1][2] and still have concerns about macros and records

>> composability and reusability. I personally don't like excessive usage

>> of them in general. By adding more macros, already quite complex guix

>> services mechanism becomes even more harder to learn, inspect, reason

>> about and work with. In addition to that it has a major technical issue

>> mentioned above. I'm strongly against this change and would suggest to

>> revert it.

>>

>> I hope it doesn't sound rude and I'm really thankful for your work on

>> this, but I just think it's not the right solution, at least yet, in its

>> current form.

>

> It does sound a bit rude. :-) I would have loved to get any feedback

> from you while we were discussing this in the course of reviewing the

> Syncthing and Dicod patches a couple of months ago (which I believe you

> were Cc’d on, as member of the Home team).

>

> I won’t argue about macros and records, it’s off-topic: macros and

> records are part of the Schemer’s toolbox, we try and use them wisely,

> and Guix code has always used macros and records. We can discuss

> whether a specific macro or record type is suitable, of course, but

> general statements about them are unhelpful.

>

> Was it ‘for-home’ that triggered your comment?

>

> The patches do not introduce any new record type IIRC; what triggered

> your comment regarding records?

>

> I’m all for making changes to improve on this patch series. I’m against

> reverting the patch series: the conditions for reverting are not met

> (info "(guix) Commit Access").

>

> Thanks for your feedback,

> Ludo’.

> On 2023-08-22 18:25, Ludovic Courtès wrote:

>

>> Hi Andrew,

>>

>> Andrew Tropin <andrew@trop.in> skribis:

>>

>>> Sorry for comming late to the party, I saw this message only a week ago

>>> and didn't have time to make an extensive reply yet, so I will share my

>>> quick thought on the most problematic part and maybe later will

>>> formulate others thoughts in more details.

>>>

>>> define-service-type-mapping looks imperative and potentially very

>>> problematic. Collecting those values in unknown order and applying this

>>> implicit transformation making a good room for foot shooting. Imagine

>>> someone would like to use his own (let's say) shepherd home service

>>> implementation and will add this to one of the source files of their

>>> channel:

>>>

>>> (define-service-type-mapping

>>> shepherd-root-service-type => my-home-shepherd-service-type)

>>>

>>> What happens if somebody will use his channel just for getting some

>>> package? Very likely it would break the build or in the worst case it

>>> will build with unexpected service implementation under the hood.

>>

>> Yes, this is always possible. Though it’s not very different from:

>>

>> (set! home-shepherd-service-type …)

>

> Yes, and and this is exactly what this solution does and in addition to

> that it hides it under the sweet define-service-type-mapping interface.

> `set!` explicitly communicates the danger of usage,

> define-service-type-mapping does not.

>

>

> 1. We introduce a global state here and infect potentially all the

> modules from all channels with it + mask it with nice interface. =>

> Now the result of evaluation depends on the order source files are

> read.

>>> Collecting those values in unknown order and applying this

>>> implicit transformation making a good room for foot shooting.

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

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

> Hi Andrew,

>

> Andrew Tropin <andrew@trop.in> skribis:

>

>> Yes, and and this is exactly what this solution does and in addition to

>> that it hides it under the sweet define-service-type-mapping interface.

>> `set!` explicitly communicates the danger of usage,

>> define-service-type-mapping does not.

>>

>>

>> 1. We introduce a global state here and infect potentially all the

>> modules from all channels with it + mask it with nice interface. => Now

>> the result of evaluation depends on the order source files are read.

>> Every channel can break valid user's configurations with perfectly legal

>> public guix API. We make reloading of the modules and REPL-driven

>> development in general a huge pain in the lower back.

>>

>>

>> 2. The service extension mechanism is already quite complex to understand

>> on its own, in addition to that the devirsity of record creation macros

>> / DSLs (define-record-type, define-record-type*, define-configuration)

>> doesn't make the situation better. We introduce one more DSL on top of

>> couple existing. => Learning curve raises even higher. Inspecting,

>> navigating and debugging such code becomes harder. It prevents future

>> extension with for-container or for-development-environment. It saves

>> couple of lines and avoids some minor repetions at the moment, but not

>> sure that it's the right way to reuse the stuff between home and system

>> services.

>

> I understand what you’re saying. I don’t necessarily agree with all of

> it because I believe abstraction is a fundamental part of programming;

> abstractions can sometimes be wrong or misleading of course, and that’s

> what we should strive to avoid.

>

> Back to this patch series, we’ve had one concrete illustration of a

> shortcoming:

>

> https://issues.guix.gnu.org/65510

>

> I’m aware of this and agree it needs to be addressed.

>

> In assessing this patch series, one should keep in mind that it solves a

> longstanding issue with Guix Home (code duplication and the inability to

> share service code with Guix System), one for which no other solution

> was proposed AFAIK.

> My own assessment, having reviewed patches adding Home services (in all

> loneliness I must say) is that the outcome is positive, in spite of the

> shortcoming mentioned above.

> in all loneliness I must say

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

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

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

> 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

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

> Hi,

>

> Andrew Tropin <andrew@trop.in> skribis:

>

>> In some previous threads on guix-devel/guix-patches I mentioned, that we

>> will maintain home services for rde separately

>> https://git.sr.ht/~abcdw/rde/tree/master/item/doc/decision-log/0004-rde-flavor-guix-services.org

>> and thus all (most of) the home services coming to guix-patches won't be

>> used by rde or me personally. Despite the fact that I would be glad to

>> help with reviews, I already work hard (almost fulltime) on guix, guile

>> and emacs ecosystem in parrallel to running from the war and probably

>> reviewing home services on guix-patches is less valuable use of my time

>> both for me and for the community.

>

> I’m disappointed that rde/Guix cooperation is a one-way street.

> Then, for clarity and to avoid misunderstandings, perhaps you should

> remove yourself from the Home team?

>

> Andrew Tropin <andrew@trop.in> skribis:

>

>> 1. One of the possible options is to use free-style configurations for

>> services, so we can reuse a lot of code and drastically decrease

>> duplication (only the service definition itself and a one configuration

>> record) and maintanance burden.

>

> We’ve had this discussion before; in the case of key/value-style

> configuration, I’m against “free-style configuration” (nginx

> configuration is a bit different).

>

> With free-style configuration (I assume you have alists/sexps in mind),

> you might end up generating invalid config files, or get obscure error

> messages, or whatever; I’ve used Gnus for decades (!), any Gnus user

> will know what I mean. This is Scheme, not Emacs Lisp/Common Lisp.

>

> [...]

>

>> 2. Another option is to rethink service extension mechanism a little bit

>> and maybe make it more polymorphic.

>> https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

>

> I very much support experimentation in this area; I’m sure there’s room

> for improvement (like Julien’s extension points, which you referred to

> in the message above).

>

> I’m not sure how that relates to factorizing Home/System services though.

>

> [...]

>

>> My point here is: let's solve this issue on another level of

>> abstraction, by improving service extension mechanism, not by creating a

>> new level of abstraction (as we did in rde or in this patch series) to

>> cover the wholes in the previous level.

>

> Do you have ideas on how you’d change service extension to support

> Home/System factorization?

>

>> I would be glad to cooperate on this and design possible improvements.

>

> I interpret this sentence as you suggesting that you’re outside the

> project—even though my perception is that you’ve been part of it for

> some time, even before you got commit rights. So do feel at Home!

> (Pun intended. :-))

> On 2023-09-13 20:06, Ludovic Courtès wrote:

>

>> Hi,

>>

>> Andrew Tropin <andrew@trop.in> skribis:

>>

>>> In some previous threads on guix-devel/guix-patches I mentioned, that we

>>> will maintain home services for rde separately

>> I’m disappointed that rde/Guix cooperation is a one-way street.

>

> That's probably a wrong statement.

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

> 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))))

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

> Hi Andrew,

>

> Andrew Tropin <andrew@trop.in> skribis:

>

>> We have

>>

>> (extensions

>> (list (service-extension account-service-type

>> (const %dicod-accounts))

>> (service-extension shepherd-root-service-type

>> dicod-shepherd-service)))

>>

>>

>> We can do

>>

>> (home-environment

>> (services

>> (list (service dicod-service-type)))

>> (service-mapping

>> `((,shepherd-root-service-type . ,home-shepherd-service-type)

>> (,account-service-type . ,ignore-service-type))))

>

> As a user writing the ‘home-environment’ declaration, I don’t want to

> know whether a Home service is implemented by mapping a System service

> to Home, or whether it’s a fully separate implementation.

>

> To me, users shouldn’t have to specify service mappings at all; service

> mapping is a tool at the disposal of service writers.

>

>> Now you can use the same service type and configuration record in

>> both operating-system and home-environment and use/ignore/interpret the

>> configuration fields values based on the environment we are building

>> this thing for.

>>

>> Of course service-mapping default value can be generated upfront and

>> stored in %guix-home-service-mapping or something like that.

>>

>> This way we will get rid of almost all home- services and related

>> configurations.

>>

>> Keep in mind that it's a raw idea, not a well-designed solution yet.

>

> The good thing is that we seem to agree on the general idea of having a

> way to map System services to Home.

>

> My take is that the mapping is an implementation detail that users do

> not need to be aware of.

>

>> The reason I'm suggesting to revert this patch series is because it

>> feels to me as a partial solution on the wrong level of abstraction,

>> which cures the symptoms and also introduces shortcomings and

>> potentially makes it harder to introduce a proper solution in the

>> future.

>

> I disagree with this assessment.

>

>> If this problem is urgent/demanding for you, please invite me for

>> working or collaborating on the solution explicitly, I plan work on it

>> anyway, but probably not earlier than the next year. I catched this

>> thread accidentially BTW, thanks to ??? for CCing me.

>

> This problem has been discussed pretty much since Home was merged in

> Guix¹; we’ve all had ample time to think about it and to my knowledge

> this patch series is the only proposal that was ever brought.

>

> I’ll close this bug for clarity. I remain open to discussion on the

> implementation of System -> Home service mapping. I think further

> discussion should happen in the context of incremental changes to the

> implementation of that mapping mechanism, in a dedicated issue.