Hartmut Goebel <h.goe...@crazy-compilers.com> skribis: > BTW: I just started typing down a simple "location" record type, and > started to think if these record types are really the way to go for the > configuration. > > In nginx AFAIK you can define many options on the server level, on the > vhost level and per location. Additionally locations can be nested. And > some configuration options are quite complex, e.g. "listen" [1] and > maybe worth their own type. So we'll create a lot of code for both the > record types and for converting them to config-file text. > > In the long run, we will get maintenance problems, I'm afraid, if we are > only allow options known to us and written into the service. On each > update we'd need to check if any option was added.
You’re right: we never want our Scheme interface to config files to be less expressive than the original config syntax. Yet, having a Scheme interface to config files is valuable: people don’t have to learn a new syntax, you get compile-time checks of field names, it’s easier to customize config represented as a Scheme object, etc. So there’s a tension here. So far, there’s no single approach to this problem in GuixSD. In some cases we don’t provide a Scheme interface at all (e.g., syslogd), which isn’t great. In other cases (e.g., nginx, Tor), we provide a partial Scheme interface along with a way to augment the config file using its native syntax. In yet other cases (CUPS, Dovecot, added by Andy, or libc’s NSS and PAM), services have a Scheme interface that cover 100% of their current config space, sometimes with the added ability to provide raw inline config. I think this last approach is the preferred approach, but it’s also more difficult to get right in some cases. For instance, nginx config is not just about key/value arguments: it has blocks, a notion of scope, etc. So nginx config syntax and semantics is more complicated than key/value configs such as that of Dovecot or Tor. > So IMHO the recard types are not the way to go. We need a more flexible > way, maybe like used for XML (see default-build.xml in > guix/build/ant-build-system.scm), but with support for default values. We could obviously use s-expressions for everything (they are essentially typed XML). However, people would get zero compile-time checks and it would also be much harder (and less efficient) to deal with them. Ludo’.
