all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Andrew Tropin <andrew@trop.in>
Cc: 65119@debbugs.gnu.org, 宋文武 <iyzsong@envs.net>, paren@disroot.org
Subject: [bug#65119] [PATCH 0/8] Sharing service code between Home and System
Date: Wed, 13 Sep 2023 21:55:20 +0200	[thread overview]
Message-ID: <87led9lufr.fsf@gnu.org> (raw)
In-Reply-To: <874jk3sk57.fsf@trop.in> (Andrew Tropin's message of "Sat, 09 Sep 2023 14:42:12 +0400")

Andrew Tropin <andrew@trop.in> skribis:

> 1. One of the possible options is to use free-style configurations for
> services, so we can reuse a lot of code and drastically decrease
> duplication (only the service definition itself and a one configuration
> record) and maintanance burden.

We’ve had this discussion before; in the case of key/value-style
configuration, I’m against “free-style configuration” (nginx
configuration is a bit different).

With free-style configuration (I assume you have alists/sexps in mind),
you might end up generating invalid config files, or get obscure error
messages, or whatever; I’ve used Gnus for decades (!), any Gnus user
will know what I mean.  This is Scheme, not Emacs Lisp/Common Lisp.

[...]

> 2. Another option is to rethink service extension mechanism a little bit
> and maybe make it more polymorphic.
> https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

I very much support experimentation in this area; I’m sure there’s room
for improvement (like Julien’s extension points, which you referred to
in the message above).

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

[...]

> My point here is: let's solve this issue on another level of
> abstraction, by improving service extension mechanism, not by creating a
> new level of abstraction (as we did in rde or in this patch series) to
> cover the wholes in the previous level.

Do you have ideas on how you’d change service extension to support
Home/System factorization?

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

I interpret this sentence as you suggesting that you’re outside the
project—even though my perception is that you’ve been part of it for
some time, even before you got commit rights.  So do feel at Home!
(Pun intended. :-))

Ludo’.




  parent reply	other threads:[~2023-09-13 19:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-06 21:04 [bug#65119] [PATCH 0/8] Sharing service code between Home and System Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 1/8] services: dicod: Remove Shepherd < 0.9.0 compatibility layer Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 2/8] services: dicod: Pre-build the GCIDE index Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 3/8] services: syncthing: Use 'match-record' Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 4/8] services: Define 'for-home' Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 5/8] home: services: Support mapping of System services to Home services Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 6/8] home: services: mcron: Define as a mapping of the system service Ludovic Courtès
2023-08-21 15:50   ` Andrew Tropin
2023-08-06 21:07 ` [bug#65119] [PATCH 7/8] home: services: Add dicod Ludovic Courtès
2023-08-06 21:07 ` [bug#65119] [PATCH 8/8] home: services: Add Syncthing Ludovic Courtès
2023-08-13  5:28 ` [bug#65119] [PATCH 0/8] Sharing service code between Home and System 宋文武 via Guix-patches via
2023-08-20 21:23   ` bug#65119: " Ludovic Courtès
2023-08-21 13:43   ` [bug#65119] " Andrew Tropin
2023-08-22 16:25     ` Ludovic Courtès
2023-08-25  6:28       ` Andrew Tropin
2023-09-08 12:42         ` Andrew Tropin
2023-09-08 22:18         ` Ludovic Courtès
2023-09-09 10:42           ` Andrew Tropin
2023-09-13 18:06             ` Ludovic Courtès
2023-09-17  5:28               ` Andrew Tropin
2023-09-17 10:27                 ` Ludovic Courtès
2023-09-13 19:55             ` Ludovic Courtès [this message]
2023-09-17  7:01               ` Andrew Tropin
2023-10-13 16:05                 ` Ludovic Courtès
2023-10-14  6:03                   ` Andrew Tropin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87led9lufr.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=65119@debbugs.gnu.org \
    --cc=andrew@trop.in \
    --cc=iyzsong@envs.net \
    --cc=paren@disroot.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.