Re: public-inbox-init with minimal info

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]