Re: [PATCH 1/2] cli: looking for config file in $XDG_CONFIG_HOME

Subject: Re: [PATCH 1/2] cli: looking for config file in $XDG_CONFIG_HOME

Date: Thu, 15 Mar 2018 13:54:29 +0000

To: David Bremner, Tomi Ollila, sh!zeeg,


From: Daniel Kahn Gillmor

On Wed 2018-03-14 22:54:06 -0300, David Bremner wrote:
> There doesn't seem to be a good reason to drop ~/.notmuch-config
> completely here. As Tomi notes, that would break notmuch for all current
> users. I suppose I could live with $XDG_CONFIG_HOME/notmuch/config (or
> whatever) taking precedence if it exists.

If we ant to keep the config file, then i agree that
$XDG_CONFIG_HOME/notmuch/config is probably the a better place for it
than ~/.notmuch-config.  But:

It seemed to me that there was a growing consensus that the configfile
could be phased out in favor of storing configuration details in the
database itself.  (this is dependent on someoneā„¢ actually doing the
implementation work, of course)

if we do this, it seems likely that we'll need to keep around handling
the config file for backward compatibility, via something like:

 * 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

    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.

after some number of versions has elapsed and we are ready to explicitly
deprecate the config file, perhaps we convert situations (a) and (b)
into warning messages and situation (c) into a hard error.

This is all a bit confusing, but it is the price we pay for having a
smooth transition that allows users to upgrade knowing they can roll
back if a new version isn't working for them.

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.

signature.asc (application/pgp-signature)
notmuch mailing list