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

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

[Reily Siegel]

Hello,

This commit at 3948ac25b1dccc40c7fdf56377f94a0775a835ee broke my
configuration. I don't mean to grumble about this, but rather
figure out if I am doing something horribly wrong in my configuration to
cause such a simple change to break things, and perhaps alert other
people making similar mistakes happen.

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.

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.

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?
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)))
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?

Thanks for reading through this email that I am for some reason sending
even though it would be faster to just add descriptions to all my
services, and hopefully I can learn something about Guix!

-- 
Reily Siegel

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

[Liliana Marie Prikler]

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

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

[Ludovic Courtès]

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