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=-4.0 required=3.0 tests=ALL_TRUSTED,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 DA8491F4BD; Fri, 4 Oct 2019 02:45:59 +0000 (UTC) Date: Fri, 4 Oct 2019 02:45:59 +0000 From: Eric Wong To: Alyssa Ross Cc: meta@public-inbox.org Subject: Re: public-inbox-init with minimal info Message-ID: <20191004024559.GA24741@dcvr> References: <87bluyhyfi.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bluyhyfi.fsf@alyssa.is> List-Id: Alyssa Ross wrote: > In NixOS, the best way for us to provide a public-inbox module would be > to generate the configuration file ahead of time, and then initialize > inboxes that don't already exist at some reasonable time during boot. > > public-inbox-init tries to write a config file in addition to > initializing an inbox. My initial idea was to just eschew > public-inbox-init for doing git init --bare myself, which works great > for V1 repositories, but I'd really like to be generating V2 ones. > > Since the V2 initialization isn't encapsulated in one easy command, I'm > wondering what the best way to accomplish initialization without writing > a config file or asking for unnecessary information is. I could just > run public-inbox-init with PI_CONFIG=/dev/null, but then it's still not > clear to me what information about the mailbox the script requires to be > able to initialize the mailbox. Looking at the code, I see that at > least the primary address is passed to PublicInbox::Inbox, but I'm not > sure what that would actually be used for inside the inbox. That address is used for making commits using the public-inbox-{learn,edit,purge} commands, and also matching with public-inbox-mda for delivery. > So, what would the best thing for me to do here be? To summarise, I'd > like to generate V2 inboxes while providing as little information about > the inbox as possible, and without writing a config file. You want to provide that inbox during the post-install? I'm not sure if I understand what's going on (but it's been a long day :x). I'm not sure if providing an inbox on package installation is necessary or even a good thing... Using git itself as an analogy: I wouldn't expect installing git to auto-generate an empty git repo for me. So same with public-inbox, and stuff like cgit/gitweb... Perhaps examples/public-inbox-config could add some newish features such as nntpserver and css support and packaged up for users, though: diff --git a/examples/public-inbox-config b/examples/public-inbox-config index 7fcbe0ba..a6785a7c 100644 --- a/examples/public-inbox-config +++ b/examples/public-inbox-config @@ -1,5 +1,13 @@ # this usually in ~/.public-inbox/config and parseable with git-config(1) # update t/config.t if changing this, that test relies on this +[publicinbox] + nntpserver = news.example.com + css = /path/to/share/public-inbox/216dark.css media=screen + css = /path/to/share/public-inbox/216light.css media=print + css = /path/to/share/public-inbox/216light.css \ + media='screen AND (prefers-color-scheme:light)' +[publicinboxwatch] + spamcheck = spamc [publicinbox "test"] address = try@public-inbox.org address = sandbox@public-inbox.org