From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 6E79D1F4BD; Tue, 8 Oct 2019 07:11:01 +0000 (UTC) Date: Tue, 8 Oct 2019 07:11:01 +0000 From: Eric Wong To: Alyssa Ross Cc: meta@public-inbox.org Subject: Re: public-inbox-init with minimal info Message-ID: <20191008071101.GA28837@dcvr> References: <87bluyhyfi.fsf@alyssa.is> <20191004024559.GA24741@dcvr> <878sq0iwt2.fsf@alyssa.is> <20191005051434.GA23947@dcvr> <87pnjb4a1f.fsf@alyssa.is> <20191005195838.nypagsfok24b5odr@dcvr> <87h84m42vc.fsf@alyssa.is> <20191006120104.GA24228@dcvr> <87tv8k5ldb.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87tv8k5ldb.fsf@alyssa.is> List-Id: Alyssa Ross wrote: > 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. > >> 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 . 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.