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 9FF0F6DE1831 for ; Sun, 18 Mar 2018 18:24:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=0.011, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KElkgMwfN5My for ; Sun, 18 Mar 2018 18:24:41 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 400456DE1830 for ; Sun, 18 Mar 2018 18:24:41 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.89) (envelope-from ) id 1exjXO-0001FT-S6; Sun, 18 Mar 2018 21:24:34 -0400 Received: (nullmailer pid 20669 invoked by uid 1000); Mon, 19 Mar 2018 01:24:33 -0000 From: David Bremner To: Daniel Kahn Gillmor , Tomi Ollila , sh!zeeg , notmuch@notmuchmail.org Subject: Re: [PATCH 1/2] cli: looking for config file in $XDG_CONFIG_HOME In-Reply-To: <87po451m22.fsf@fifthhorseman.net> References: <20180314124321.13848-1-shizeeque@gmail.com> <87d106qf29.fsf@tethera.net> <87po451m22.fsf@fifthhorseman.net> Date: Sun, 18 Mar 2018 22:24:33 -0300 Message-ID: <87d100luwe.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.26 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: Mon, 19 Mar 2018 01:24:42 -0000 Daniel Kahn Gillmor writes: > > * when we observe a config file, we could walk each option present in > it. For each option: > > a) if that option is not present in the database, copy it into the > database. > > b) if that option is present in the database, and it matches the > option in the config file, ignore > > c) if that option is present in the database but does not match the > config file, use the version in the config file but warn the user > that they have a conflict they should probably resolve soon. I guess this whole discussion is about the CLI, so in principle that's OK, but for existing library code there's no real way to use the config file value for config values that are stored in the database: we just don't pass that information in to the API. What's (relatively) easy is to have the config file reader used by the CLI check for conflicts with the database config and report those. We could also give people a flag (or something) so that the database version of the config is overwritten. Really, writing the database config from the text config file seems relatively sane to me. It's editing that file via computer that gives me the heebie-jeebies. > So i think it would be a shame to have an additional layer of confusion > added by having two different deprecated configuration files. So i lean > against adopting this change. I'd much rather see work on phasing out > the configfile. OK, noted. I guess I would imagine any conflict resolution to be against the in-memory struct read from disk, so somewhat orthogonal to where it is read from.