Re: public-inbox-init with minimal info

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

Alyssa Ross <hi@alyssa.is> wrote:

<snip>

> Eric Wong wrote:
> > Does Nix allow users to set things in the config file directly?
> > (instead of going through the functional language).
> 
> It does; see below.

<snip>

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

Ah, so that overrides the Plack::Builder DSL/language.  We also
have an analogous support problem for PSGI vs public-inbox-config,
so I've been avoiding any overlap between them.

Perhaps "psgi_mount" would be clearer? *shrug*

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

Cool.  An upside for non-NixOS users is we get more experienced
and clueful maintainers reporting bugs to upstream as a result :)

Btw, would it be helpful if public-inbox provided a linter for
its config own file?

I'm actually thinking of doing some sort of graphing tool using
Graph::Easy to visualize all the relationships between various
components, and maybe it can parse the config file to show
people how things work; and it could do the linting as a side-effect.

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

Thanks, that is all very reassuring to read.