Subject: [bug#65119] [PATCH 0/8] Sharing service code between Home and System

From: Ludovic Courtès <[email-masked]>
Date: Tue, 22 Aug 2023 18:25:22 +0200

Hi Andrew,

Andrew Tropin <[email-masked]> 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’.