GNU bug report logs - #27155
[PATCH 0/2] Support service extensions on the "final" service values

Previous Next

Full log

View this message in rfc822 format

From: Rutherther <rutherther <at> ditigal.xyz>
To: 27155 <at> debbugs.gnu.org
Cc: Ricardo Wurmus <rekado <at> elephly.net>, Ludovic Courtès <ludo <at> gnu.org>
Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final"
Date: Sun, 16 Mar 2025 12:47:21 +0100

Hello Ludo and Ricardo,

what's the state of this? Why has this been abandoned?
I am really missing a feature like this, so it pains me to see
an abandoned thread that clearly states (and I agree) that this
feature has been long overdue, but now it's been even 8 more years longer!

For example, I would like to change the home mcron shepherd service so that it gets
a wayland display env var. Currently it is possible to modify leaf services
somewhat, as I can just override the service-type and change the
service, but this won't be working with non-leaf one as the original
service-type is extended. This complicates the process by a lot.

I think that if this was merged, it would be possible to start adding
other functions to guix that would be modifying shepherd services,
ie. some sort of a general modify-shepherd-service and then on
top of it functions to modify specific things, like dont-autostart-shepherd-service.

I am willing to put some work into this just say
what's missing here, because I don't know (apart from the obvious that
this code probably won't cleanly apply - but I haven't tried to be honest).

> > I think it is useful to have the ability to add rewriters at the end of
> > service composition.  In my opinion it is always good to have an escape
> > hatch, and this seems to fit the bill.  But I agree that it is not
> > an elegant solution, and I wouldn=E2=80=99t want to advocate using it.

> Right.  As discussed on IRC, one problem is ordering: if there are
> several users of this features for a given service, you can=E2=80=99t really
> tell what=E2=80=99s going to happen, unless the modifications happen to be
> commutable.

As for ordering, since I was using NixOS, I know a way they solve issue
like this. Your system config there is composed of many options that
you set to values. One option can be set multiple times, and if that
happens, there are two possibilities - either both have same priority
and the type is composable, then both values are used and it is
composed with a function (ie. if you have lines type and you add
two values, it will get merged with \n). If it is not composable,
and error is thrown. If both have different priorities, the higher
priority is used.

So using something like this for this case - finalization could accept
functions along with priorities - maybe a record?. If same priority is used,
(finalization1 (finalization2 original-config)) is used,
if not, the one with higher priority is used. Imo this would allow
for more use cases, even though of course it's not perfect - sometimes
options just aren't composable well.

This would solve an issue where if a service creator making a service
in a channel decides to use this feature, the end user can still easily
override the original finalization function, or deliberately
make their change composable, so both finalization procedures
can be called fine.

Regards,
Rutherther

Previous Next

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