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

[Andrew Tropin]

On 2023-09-09 00:18, Ludovic Courtès wrote:

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

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.
https://yhetil.org/guix/87ild88kax.fsf@trop.in/

We have only two maintainers and have more than the half of a hundred
services in rde, which is not that far from guix itself (258 services).



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

(Just making a rough example of naive implementation) Instead of
referencing service by it's value, we could reference its name.  This
way we can write one service for Home and System, which always extends
'system-accounts-service-type, and for home case provide a different
implementation for it, so when we build operating system
system-accounts-service-type will add users to /etc/passwd, when we
build home-environment system-accounts-service-type will do nothing.

Adjusting the logic of the extension based on presence/absence of a
particular service can be very useful to make it possible to reuse
configuration for Home and System services directly.

However, improving service extension mechanism in such way, keeping
backward compatibility and upstreaming it is a hard and very
time-consuming task.  So in rde we just implemented a feature mechanism
on top of service extension mechanism to solve challenges mentioned
above and it works great.  It would be even greater if we could just do
the same with plain services.


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.

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

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

I think that your concern about code duplication is valid (and I'm aware
of the issue probably even longer :) ) and I would be glad to cooperate
to solve it.  However, I'm almost sure that it should be done on service
extension mechanism level.  If this make sense, we can discuss possible
solutions in more details and next practical steps.

-- 
Best regards,
Andrew Tropin

signature.asc
Description: PGP signature