GNU bug report logs - #65119
[PATCH 0/8] Sharing service code between Home and System

Previous Next

Full log

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.