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

[Andrew Tropin <andrew@trop.in>]

[-- Attachment #1: Type: text/plain, Size: 4184 bytes --]

On 2023-09-13 21:55, Ludovic Courtès wrote:

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]