Re: public-inbox-init with minimal info

[Alyssa Ross <hi@alyssa.is>]

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

> 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 <https://nixos.org/nixos/options.html>.  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.

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