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

[Jani Nikula]

On Thu, 15 Mar 2018, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 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)

What about configuration specific to the CLI that is irrelevant for the
library/database? Do you propose to store those in the database too? For
example user.name or crypto.gpg_path. And then there's the database
location, which obviously can't be in the database.

For database specific configuration that currently lies in the CLI
config, there's also a bunch of rework required. For example, if we
store new.tags in the database, what would be the point of the CLI
reading those out of the database, and then applying them to the
message? Shouldn't the new.tags be applied to the messages at the
library level directly? Ditto for search.exclude_tags and
maildir.synchronize_flags.

Where's the point in moving all this stuff to the database, unless we
also use them directly in the database?

> 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
>        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.

Wouldn't this require having an in-memory copy of the database config,
where the items originating from the config file would override but not
get saved into the on-disk version of the database config?

> 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.

I think it's more confusing than you think. ;)

I also kind of like the CLI config file that I can just save in git
along with my other dotfiles. The database config is much more annoying
in this regard.

> 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.

Agreed on not increasing the confusion, at least not before we figure
out what we want to do.

BR,
Jani.