Re: Breaking change: Make 'description' of <service-type> mandatory

["Ludovic Courtès" <ludo@gnu.org>]

Hello Reily,

Apologies for the breakage cause by this change.

Reily Siegel <mail@reilysiegel.com> skribis:

> The problem arises when a certain feature needs to extend two services
> to be useful: take configuration of an emacs package. It must first
> extend (in the case of Guix home) home-emacs-service (from RDE channel)
> with the emacs configuration to be inserted to init.el, and
> home-profile-service-type, to add the emacs package to the profile. It
> seems like simple-service /would/ be a good option here, except as best
> I can figure out it can only extend one service. So instead, I create a
> new service-type, perhaps named my-emacs-feature-configuration-service,
> which takes no value and has no extension mechanism, but only serves to
> extend multiple other "real" services.

OK, that sounds reasonable to me.

> This change (and the discussion at https://issues.guix.gnu.org/55404)
> indicates to me that all service-types, no matter where they are
> implemented, are meant to be consumed by a generic user, not used in a
> one-off way like my configuration does.

I’m not sure what you mean by “generic user”.  The focus in the
discussion above was on all the service types defined within the Guix
repo, but that doesn’t mean one cannot define service types elsewhere.

If you’re defining one-off service types, perhaps adding a ‘description’
feels overkill.

> So, to sum up, I have a few questions:
>
> 1. Is service-type meant for use in individual user configurations?

Sure, if it’s useful, why not: it’s part of the public API.

> 2. Is there an equivalent function to simple-service that takes multiple
>    service/value pairs that I have missed?
>    (e.g., (simple-service-like service-a val-a service-b val-b ...)
>     or (simple-service-like (list service-a val-a service-b val-b)))

No, but we could define one, or perhaps just extend ‘simple-service’ to
three or more arguments instead of just three?

> 3. If the answer to 2 is no, does it make sense to extend simple-service
>    to work with multiple service extensions, or is there some reason for
>    only extending one service at a time?

The only reason ‘simple-service’ extends a single service type is that
it seemed to be a common use case back then.

Thanks for your feedback!

Ludo’.