>> 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. I'm guessing those read from the config file, though? I'm trying to figure out what configuration is stored in the inbox directory as opposed to the 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... I agree -- creating an inbox on package installation would be a terrible idea, and is not what I'm proposing to do. Some background: in the Nix ecosystem, we have a package repository, Nixpkgs. These packages are fairly typical except for unusual paths (containing checksums of the "inputs" -- think dependencies -- of the package) and the functional language they're written in. We also have NixOS, which is a GNU/Linux distribution, that uses those packages but also adds the concept of "modules", written in the same language as the packages. These modules do things like configuring the users on your system, setting up config files, etc. The idea being that you can generate a whole Linux system from pure (in the functional programming sense) configuration, reproducibly, and have the system stuff be read only at runtime to the maximum extent possible. I'm working on both a package _and_ a module for public-inbox. The package will do exactly what you'd expect a package to do, but the module will let you express global and per-inbox configuration in the Nix language, generate a read-only public-inbox config file and systemd units from those, and, at boot time or configuration change time, initialize the inboxes defined by the user. As an example, Tor in NixOS looks like this: { ... }: { services.tor.enable = true; services.tor.hiddenServices = [ { name = "public-inbox"; map = [ { port = 80; destination = 8000; } ]; version = 3; }; ]; }; This will generate a static tor.service and tor config file -- we do as much as possible staticly and purely because then we know that if a configuration is rolled back, we can remove the service etc. For state, however, like the hidden service private key (in this case -- I could have used a static one here if I'd wanted), it will be generated either at boot time or in Tor's ExecStartPre. This is the same mechanism I would use to run public-inbox-init.