Hi Maxim, On Fri, Oct 24 2025, Maxim Cournoyer wrote: > Personally, I find there are many nice properties from doing things the > way it's currently done in Guix. [...]
Sure, I'm not arguing there's no value. Merely that the benefits don't outweigh the costs. > For one, the configuration records are documented and can be found in > the `info guix` manual, quickly accessible via the Texinfo indexes > (i). [...] This is a benefit, but this is also a cost, in two ways: 1. Invariably, Guix does not implement all configuration options for a service (e.g. mumble-server-service-type does not have defaultchannel or rememberchannelduration), so relying on Guix's documentation is like using an incomplete form of the upstream documentation. 2. Guix's documentation of options is usually pretty brief. Often this means that I can't actually rely on the info pages to know how things work, I need to find the upstream documentation for the right options (which usually means reversing Guix's kebab-case renaming, but sometimes involves more substantially reading the service code to find the translation). It is convenient to have options documented in the Guix info pages, but I question whether "re-document upstream options, but worse" is a winning strategy. If we really want to document upstream options, there's no reason we couldn't document the options that can be set in service configuration files (without requiring the Scheme records). > It's also human-readable in your config.scm file. Most configuration formats are human-readable. Having strings scattered throughout a Scheme file might be messy (although I don't mind it in my configs), but we could improve this with more generic functions to generate config files. I haven't used it, but I believe rde does this[1]. > Of course covering all of the services and options imaginable may not be > possible, and we don't have too. Most service configuration objects have > some escape hatch (field) to input literal configuration fragments, so > that users can still do anything they want even if it's an unusual thing > to do that hasn't been exposed in the configuration record of a service. I don't think it's unusual to want to set a default channel in Mumble. Framing "I want to set an option that Guix doesn't support" as "unusual" assumes that Guix's configuration options are sufficient for all "usual" uses. I disagree with this framing. I also want to clarify: I'm not suggesting to get rid of all options. Any options that control Guix's behaviour (e.g. auto-start? which affects a service's Shepherd service) should absolutely stay, because they are Guix features. But any options where someone asking a question in #guix would be answered by "check the upstream documentation" should be reconsidered. Carlo [1]: An example for nginx configurations: https://git.sr.ht/~abcdw/rde/tree/master/item/src/rde/serializers/nginx.scm
