From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id AF2356DE0C51 for ; Wed, 13 Dec 2017 17:28:12 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=-0.009] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRr50TWZVkQ2 for ; Wed, 13 Dec 2017 17:28:12 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTPS id C5C456DE0C45 for ; Wed, 13 Dec 2017 17:28:11 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id A55FAF99D; Wed, 13 Dec 2017 20:28:08 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id F03EA2086D; Wed, 13 Dec 2017 18:47:10 -0500 (EST) From: Daniel Kahn Gillmor To: Carl Worth , David Bremner , Adam Washington , notmuch@notmuchmail.org Subject: config file vs. config in the database [was: Re: Possible bug with named queries] In-Reply-To: <87k1xqcjj0.fsf@wondoo.home.cworth.org> References: <871sjyiwwx.fsf@stfc.ac.uk> <87k1xq37gr.fsf@tethera.net> <87k1xqcjj0.fsf@wondoo.home.cworth.org> Date: Wed, 13 Dec 2017 18:47:07 -0500 Message-ID: <87mv2mtclg.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:28:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carl, all-- thanks for raising this subject! I've taken this opportunity to write down a bit more justification for why i lean in the direction that Bremner describes, but would be happy to be argued out of it. On Wed 2017-12-13 15:09:23 -0800, Carl Worth wrote: > Really? We're deprecating the ability to just edit the configuration > file by hand? That's unfortunate. the interaction between the config file and libnotmuch is particularly problematic -- the config file tends to be something dealt with by the notmuch cli, but that means that MUAs built on notmuch that *don't* use the cli as the backend (that is, which use the library directly) don't get the same advantages. Also, having two different config files that apply to the same database presents a not-insignificant logistical challenge -- is it possible to set configurations that will apply to all accesses that happen to a given database? the right place to store those configuration choices is *in the database itself*. > But if running "notmuch config" to add a saved search stores some > necessary data in the database, couldn't the same code be invoked when > loading the configuration file and noticing a new saved search there in > the file? i would support a changeset that does this for the cli, that's a good idea. But as mentioned before, it's not clear when this code would be invoked by a MUA that uses the library directly. how would you ensure that they stay in sync? also, if the database already has a stored query of the same name, should it be overwritten by the one in the config file? Should it be removed from the config file once it has been stored in the database? if i want to see a list of all my saved searches, where should i look? > We've gone out of our way to make the configuration file as useful as > possible, (such as by maintaining comments in the file even when using a > tool such as "notmuch config" to edit it). Let's please not throw out > all the benefits by just saying that manually editing the configuration > file is unreliable and people shouldn't do it. I actually think that the notmuch config file is far from "as useful as possible". :( More concerns with the notmuch configuration file will follow below. If i had the time and energy, and no more pressing goals for notmuch, i would probably submit a patch that removes every option from the configuration file except for the location of the database itself. and i'd warn users of the cli about the presence of any other configuration that remains in their personal configuration file. I'd even like to see notmuch usable without a configuration file at all, by selecting a default location for the database path (though i don't have the political stamina today to fight the inevitable fight about where that path would be). I'm happy to hear pushback on this mini-agenda of mine, to better understand why people want to edit and read this file by hand, but i currently see the config file as the cause of several minor papercuts/annoyances, and not a lot of ways that it helps. writing defaults to the config file =2D---------------------------------- the current notmuch configuration subsystem actively writes the defaults into the config file upon first initializing it means that there is no way for a user to say "keep this setting as its default". Consider a simple boolean setting, which defaults initially to false. Anyone who sets up a config file gets it written down as false. over time, the project evolves and the new default of the setting is true. but everyone who moves to the new version from the old one retains "false" for that config setting, *even if they have never explicitly set it to false*, because notmuch (rightly) doesn't want to change the values in the file. writing standard comments to the config file =2D------------------------------------------- by default, when notmuch creates an initial config file, it stuffs a bunch of comments about what goes there in it, in addition to including the initial settings themselves. My experience with heavily-commented, detailed, per-user configuration files is that they are great ways to accumulate cruft over time. For an installation of complex software that has existed over years, any user's configuration file that contains auto-generated comments or auto-written values likely contains choices or information that are *factually wrong* for the current version of the software that they're using. This is the reason i pushed GnuPG into getting rid of their default configuration file. Modern versions of gpg do not create a gpg.conf at all, and (usually) Just Work=E2=84=A2 without anything there. Each install= ation still ships documentation about what options *can* go in the config file, though. Notmuch has a good documentation system, and the configuration options for the currently-installed version of notmuch are well-documented in notmuch-config(1), along with their defaults. We shouldn't be using the user's configuration file as a place to stash software documentation. using the human-readable config file for "safe backup" =2D----------------------------------------------------- One advantage of the human-readable config file is that it can provide a backup format, no matter how xapian or notmuch changes in the future. a plain text serialization/deserialization format is a handy thing to have. however, we already have that with "notmuch dump" and "notmuch restore", and it's not clear that the config file offers any advantage over those subcommands for the purposes of backup and restore. arguably, the config file is marginally worse, because it means that you have to back up two things instead of of one if you want a recoverable text-based backup. using the config file for the user's notes about notmuch configuration =2D--------------------------------------------------------------------- the one thing my proposal above doesn't cover is a place for users to put notes about why they've chosen a particular configuration option, which they can currently do in comments in the config file. I don't actually have a proposal for how to deal with this, other than to observe that if there was no config file, users could still take notes anywhere (including wherever it is that they take notes about how they choose to use their web browser, their word processor, their compiler, etc). If someone wants to propose an improvement here, i'm all ears. Do people want to offer examples of user-written notes that they have as comments in their config file that they would be sad about losing if the config file were to go away? All the best, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAloxu/sACgkQFJitxsGS MjdO/A/7BGjUZZ2I1rK31agwj4kBNhivBENhlyKNeX0k1w/cBtB+UmpuHuC6uak2 +uGYwqYsM/UPVHcef3y5pPrmFUUKtkJp3GznSSdjwFxsXxs7Fml2cFRhOR1JcBkK aoqXv/n4fUnA0JC9b66O9NeTgfSzAx5C8GtU3r06iOqS6uKOeXuOATYDASx3Nlnn 1XPKwGWGpctuFP2w1qJVLokhWPvIYNN245JAn1NgKolgcqa1x+rXta9PJrtFiJsl 51lmwGDKYKCJ5lbIDlAKkG1XNpKI/crAlzJ4DGI+PftYpMvmYoi/3P+E1iFcXtcN FWIIqQzmNxzuRqh7SJ5UgBIBKS2qjjsy+xPt/7YCW8jUN1jHWk+niKtPdsX2WXBl WEJi6KfHb4oKpoVyFJwayeUhtHdwfK7azf1REF1bvBfV+rkmrAatkAhO6VYAxbY9 QOI08q/qipWhj4A1EKzrP+UEe7UCwJ6wQwCVNNVyegNZl5IR1Zcj2v+zIft43Dmf 4BKAm52s+fQibhXOMt0QAYZBxKPnorcrfwpx2kCaQ631Q61sZ1qUSiqwx63dC8cY b+gnbTSO86JugFYlnotyzfnC4VYe+QQ+AwTj9BP2Uq/ZyHIhYHkEzRc6Fl5dKd/m KV7k3XEBEZ6yp8fD9yhLrt9jWvyDYAebQ0CWPnORV+WO1c0O6Vk= =hSh/ -----END PGP SIGNATURE----- --=-=-=--