Hi Ludovic, On Fri, Oct 24 2025, Ludovic Courtès wrote: > Yes, that and general convenience. For instance, I find it nice to be > able to factorize bits of nginx or ‘home-openssh-configuration’ using > the familiar Scheme mechanisms: procedures, variables, etc.
Does this need to live in the service itself? I agree this is nice to have, but I think it makes services themselves unnecessarily complex. Another option would be to have the service itself only have structure insofar as it's necessary for service extensions, and then have helper functions to assemble configuration files/fragments which are passed directly into the service. We can then also provide differing levels of help for assembling configuration files. From "use this file/string as the config file", to "convert these lists/atoms to an ini/json/whatever file", to "construct a config file specifically for this service with these options". > [...] In my ideal vision of making system configuration approachable to all, > not just experts, I think it even plays a crucial role. Out of interest, do you think we are achieving this with our current approach? I think we're getting the worst of both worlds at the moment. Getting a service to work requires understanding the upstream software and its options, as well as knowing how to express those options in Guix's configuration language. I think this might marginally improve things for Guix experts, but I doubt it's helpful for non-experts, and I think it makes things harder for experts of the upstream software. I'm really on board for the vision of Guix enabling non-experts to configure systems, but I think this would be best served by Guix providing opinionated services at a higher level. Things like a "static-website-service-type" which sets up nginx, certbot, and a user for uploading via ssh/rsync; or a "laptop-service-type" which sets up whatever services make sense for that. Carlo
