Re: public-inbox-init with minimal info

[Eric Wong <e@80x24.org>]

Alyssa Ross <hi@alyssa.is> wrote:
> >> 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

OK, it seems like you can "build" the full public-inbox config
file the same way you'd build your cgitrc.

> > 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.

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)

> 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 ];

They'll all need git, too (unless that's in the default path).
Also, httpd/nntpd don't need spamassassin.

>     services.public-inbox.mda.spamCheck = "spamc";

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).

Does Nix allow users to set things in the config file directly?
(instead of going through the functional language).

I'm also not sure if you need to have
"services.public-inbox.mda.spamCheck" at all, since "spamc"
is the default value.

>     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...

>     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.

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.