On Extensions and Features

[Michal Atlas <michal_atlas+gnu@posteo.net>]

Hello Guix,

There have been a few mentions of rde features on here but were 
generally skimmed over, still I think
there's an interesting idea here.

They seem to address a few things, allowing a changing set of services 
based on the arguments,
coupling home and system and
passing around configuration inside the service system.

The last one gnawed at me until I realized that services do sensibly 
have a one way
flow of extensions forming a DAG, but the extension can be made only 
from one side.
There isn't really a way for a service to force another service to 
extend it.

This is scheme so obviously one could forcefully mutate or inherit and 
substitute, but this
starts to break down quick when we wish to combine services
from different channels and risks collisions and replacing a lot of 
service-types.

So the general idea could be to have the reverse extensions listed (hooks),
and their values passed to the extension procedures.

something like:

#+BEGIN_SRC scheme
(service-type
   (name 'home-bash)
   (extensions (list (service-extension home-xdg-data-service-type
                       (lambda (config alias-value) ...))))
   (hooks (list home-alias-service-type))
   ...)
#+END_SRC

Since when one wants to switch out their shell, or have multiple,
this'd allow them all to take the output of one canonical service that 
provides the alist of aliases the user wants.
(obviously questionable if one wants to generally do that but it could 
be toggleable)
Same could apply to user-information in guix home, keyboard preferences,
a web frontend to a service automatically knowing what port the backend 
runs on,
creating some kind of internal users of a program mirroring the system ones,
firewall rules, or whatever else.
Or, if one didn't require the service to exist and it returned #f in 
such a case,
then for example podman could link a docker compatibility binary iff it 
didn't find docker on the system.

Yes, it could easily be argued that my examples are quite dubious,
but it's just a random idea I wanted opinions on.

And since this is being in a sense replicated by features,
it'd be a nice way of merging a part of them upstream without opinionation,
and users might eventually find more and more actual uses for it,
with services making more educated decisions based on the system at hand,
and users won't have to implement something of the same sort in userspace.

It is undeniably a change towards much more expressive services
and it should be non-disruptive to existing code which defaults to 
"reverse-extending" no services.
fold-services would need a rework other than that I think it'd be 
straightforward.
(which is obviously easier said than done).

The question is how high/low-level the interface to services should be,
since a lot can be done with a few LETs and λs if services are supposed 
to be dead simple,
but such an approach makes it harder to build up well interacting services.

So that was just a very immature idea of what could be a nice to have in 
Guix.

Cheers