Re: Breaking change: Make 'description' of mandatory
Hello Reily, Apologies for the breakage cause by this change. Reily Siegel 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’.
Re: Breaking change: Make 'description' of mandatory
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
Breaking change: Make 'description' of mandatory
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