Hi Lilah, On Mon, Oct 20 2025, Lilah Tascheter wrote: > I've been wondering about the role of Guix in system configuration - we, > of course, want to support configuration of an entire system, services > included, in the system configuration. this is great, however, the > extent to which this has done, seems to have informally organized around > replicating large amounts of service-specific minute configuration and > documentation.
I agree that this is a problem. Guix essentially ends up inheriting all of the complexity of the underlying services. Rather than building an abstraction, in many cases we're just writing a translation of a configuration format into Scheme records. I don't understand why. I don't think the benefit is worth the cost in general. However, I do think there is an important exception: service extension. Take nginx for example. The ability to have other services inject server blocks into the nginx configuration file is great. I don't think it matters much whether the injected object is a Scheme configuration object, a nested set of lists representing the nginx configuration syntax, or even just a string that gets spliced in. The interface of extension is a meaningful abstraction, and is really useful for assembling services. I don't think I would miss the rest of the configuration objects if they went away. I already opt for the "opaque" configuration option for a bunch of my services because it's easier to craft exactly what I need, and it's easier to connect it to upstream documentation. My preference would be to think hard about service extensions, and create the minimal service-specific structure we need to support the extensions we want. Apart from that, leave things as free-form strings/gexps. Carlo
