> OK, it seems like you can "build" the full public-inbox config > file the same way you'd build your cgitrc. Yep! I've had that working for a couple of weeks now and it's working great! > Yeah, I run -httpd, -nntpd, and -watch as services (see examples/ dir); > so it makes sense to have those in a package. -httpd/-nntpd > generally run on the same machines, but they don't need -watch > on the same server (they can be running off git-clone/fetch && > public-inbox-index) I haven't looked into watch yet -- I've been implementing for my use case first, which is using public-inbox as an archiver for a mailing list hosted on the same server. But that does make sense, and I'll make sure to account for it. >> # Add spamassassin to the PATH of public-inbox-mda, >> # public-inbox-watch, etc. >> services.public-inbox.path = with pkgs; [ spamassassin ]; > > They'll all need git, too (unless that's in the default path). > Also, httpd/nntpd don't need spamassassin. Yeah, this is only for -mda and -watch. git is just added to the PATH of every public-inbox-* executable in the package using a wrapper script. > Note: one slight oddity is there's also a "publicinboxwatch.spamc" > in addition to "publicinboxmda.spamc"... I figure some folks will > want differently-configured spamcheckers depending on whether the > mail hits -mda or -watch (so -watch defaults to not having a > spamchecker at all). Noticed that, and will account for it. As above, I'm just not using -watch in my setup. > Does Nix allow users to set things in the config file directly? > (instead of going through the functional language). It does; see below. > I'm also not sure if you need to have > "services.public-inbox.mda.spamCheck" at all, since "spamc" > is the default value. Correct -- that's a remnant of when I had it disabled because I hadn't set up spamassassin yet. I should have deleted the line rather than changing it. >> services.public-inbox.http.mount = "/lists/archives/"; > > I think all the services would want access to the same > directories, not just httpd (if I'm understanding that config > correctly). Also, httpd/nntpd only need read-only access to their > mount points, in case that affects things... "mount" here is in the PSGI sense, not the file system sense. My public-inboxes are at https://example.org/lists/archives/. Maybe there's a better name. > The purity and rollback parts definitely sound good :) > > However, I'm wondering what level of customization can be > supported by editing the public-inbox config directly? (instead > of using the Nix language) > > Having both an upstream and distro-specific ways to configure the > same thing could be confusing to both users and people trying to > help them. > > I can agree with things like PATH, environment variables, > services-to-enable and mount-points being environment and/or > distro-specific. The rest (everything in public-inbox-config(5)), > I'm not sure about; it would increase support/doc overhead. We accept that we can't package every option and have two conventions for making sure that our users can always use every option upstream gives them. One is to provide an option called extraConfig, which just adds a string verbatim to the end of the configuration file. The other is to provide an option called config, which is structured Nix that gets turned into the appropriate configuration. The latter is preferred, because then from our point of view the configuration is still structured, and can be read back in Nix without having to parse a string, etc. Since public-inbox's configuration format is well-defined as git config, there's no reason to support the former. So, supposing you introduce a new option, publicinbox.foo, and the NixOS module hasn't yet been updated to support it natively yet. In that case, a user could use this option as an escape hatch to use it anyway: services.public-inbox.config = { publicinbox.foo = "bar"; }; This will then be compiled into git config using a function I've written that essentially runs git config --add for each config option to build up a configuration file. By now I'm sure you're wondering "why bother adding individual NixOS options for each setting at all, if you can do this?", and there are a couple of reasons why we try to do it anyway. One is that we can do type checking -- setting publicinboxmda.spamcheck to "invalid" can be a build-time failure rather than a runtime one. The other is that we can provide documentation for each option, and our users can see documentation for every option available on their NixOS system in one place at . We regularly hear from users that this is one of their favourite things about NixOS. A single place to search configuration options for every package they use. I hear your concerns about this being difficult for people trying to help NixOS users with public-inbox. It's absolutely not my goal to fragment the ecosystem. I'm not aware of this having been a significant issue for any of the hundreds of modules we have so far. Users seem to be generally pretty good at figuring out what's a NixOS issue and what's an upstream issue, and, if a NixOS user does need upstream support, it's still easy enough for them to find the generated configuration file to share with non-NixOS users. Overall, we've found that the benefits of "heavyweight" NixOS modules, for want of a better term, outweigh the disadvantages. Should this end up having a negative impact on the public-inbox system, I'd be happy to review the approach. But I think that instead, we'll end up with public-inbox being accessible to more people by being available with the advantages of NixOS -- declarative configuration, reproducibility, near-atomic updates and rollbacks, etc.