>> I've been using cgit fine with a readonly config for ages, fwiw. > > Is that possible without scan-path/project-list options in cgitrc? > public-inbox has nothing analogous to those options, right now. Yes, because I can generate my cgit configuration file with Nix. Theer's no static config file or anything -- it's generated from the configuration options provided by the user. So, as a user of cgit in NixOS, I can define my repositories, and the paths to them in Nix, and when I "rebuild"[1] my system the cgit configuration file is generated based on that. [1]: conceptually an update, but works by generating a new system configuration without referring to the current one, so it's more like rebuilding from scratch > one systemd service == one tor process, right? I haven't looked > too deeply into systemd, though, so maybe there's some way to > add services to an existing tor process... At least in this case, yes, one systemd service == one tor process. We don't support more than one, AFAIK. That would have to be done in a container or something. > I tried to make the defaults reasonable, so I don't think any > config is needed outside of what's required to map > inboxes/addresses to directories (which public-inbox-init does) The only one I've really added so far that affects the public-inbox config is whether to enable spam checking or not, but I suspect there might be more. There are also options for things like whether a service should be generated to run public-inbox-httpd, etc. Here's what my configuration looks like so far, using the module I'm writing: services.public-inbox.enable = true; # Add spamassassin to the PATH of public-inbox-mda, # public-inbox-watch, etc. services.public-inbox.path = with pkgs; [ spamassassin ]; services.public-inbox.mda.spamCheck = "spamc"; services.public-inbox.http.mount = "/lists/archives/"; services.public-inbox.inboxes = { [...] }; As you can see, it's in some ways like just writing a public-inbox configuration file, but it can go beyond that too -- there can be options like services.public-inbox.path that are more of a packaging but that can be delegated to a user (by default, services on NixOS have almost nothing in their PATH to ensure purity). I'm probably not the best person to explain why NixOS modules are good, or the benefits of expressing all system configuration in a single functional programming language, so suffice it to say that doing these things are the fundamental goals of the distribution, and that it works extremely well.