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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Donnerstag, dem 26.05.2022 um 09:38 +0200 schrieb Reily Siegel:
> The solution here is incredibly obvious, I just need to add
> descriptions to services I declare in my configuration, but that this
> change happened, and I didn't see anyone else have issues on guix-
> devel, guix-help, or elsewhere (I may have missed something), I
> thought it a good idea to ask if I am doing something unsupported in
> my configuration.
I don't think so.  Patches tend to sleep in the mailing list for a
while (the documentation says something about 14 days, but patches have
been pushed quicker than that).  People in a similar situation likely
have already noticed and documented their services in advance; even if
not, someone always has to be the first to publicly notice.

> 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.
To be fair, that's a pretty weird design for design sake.  You could
for instance make it s.t. your service takes a list of package+snippet
pairs as configuration, adding the package to your profile and the
snippet to your init.el.  That'd be more generic than a "one-off"
definition that only carries your own configuration.

> 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.
> 
> So, to sum up, I have a few questions:
> 
> 1. Is service-type meant for use in individual user configurations?
Yes and no.  You can freely define new service types if it helps you,
but the way you describe seems like a somewhat large hammer.  If your
service type provides no useful abstraction, why not use simple
services instead, even if you have to write multiple ones?

> 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)))
You can group multiple simple-services into a list, i.e. 
  (define my-service-collection
    (list (simple-service service-a val-a)
          (simple-service service-b val-b)))
and then add that to your configuration via append.

> 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?
No, you're nail-seeking.  Just because one way of doing things has
vanished doesn't mean that there aren't others that end up with the
same result.  As an analogy, (template) metaprogramming in C++ is
Turing-complete, so you could, for example, write a program that
computes a specific instance of 3SAT at compile time and the compiled
program will either be puts("yes") or puts("no"), depending on whether
the formula was satisfiable or not.  While incredibly cool, doing that
serves no real purpose – the compiled program does not solve 3SAT, it's
essentially hello world.  


Service types without configuration in a similar manner "do nothing",
i.e. they don't offer a way for the user to express their desired
system more concisely than if they didn't have them.  Once you do have
a configuration, you have to think about what parts of your system it
abstracts and makes easier to configure, ad so on and so forth, thus
naturally leading to some documentation.

I wasn't involved in any discussion around this feature, so you might
want to take my opinion with a grain of salt; nevertheless I hope it's
useful to think about things in that way.

Documenting your service types should also be more helpful if you ever
want to share them with upstream, though in the particular case of Guix
Home that's split in two very distinct realms that might not be as
simple as I've just said.

Cheers