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
