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

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

[sh!zeeg]

According to XDG Base Directory Specification
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
configuration files should be stored in $XDG_CONFIG_HOME which
defaulted to $HOME/.config/
---
 notmuch-config.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/notmuch-config.c b/notmuch-config.c
index e1b16609..7651c912 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -293,7 +293,7 @@ out:
 /* Open the named notmuch configuration file. If the filename is NULL,
  * the value of the environment variable $NOTMUCH_CONFIG will be used.
  * If $NOTMUCH_CONFIG is unset, the default configuration file
- * ($HOME/.notmuch-config) will be used.
+ * ($XDG_CONFIG_HOME/notmuch/config) will be used.
  *
  * If any error occurs, (out of memory, or a permission-denied error,
  * etc.), this function will print a message to stderr and return
@@ -358,8 +358,10 @@ notmuch_config_open (void *ctx,
 	config->filename = talloc_strdup (config, filename);
     } else if ((notmuch_config_env = getenv ("NOTMUCH_CONFIG"))) {
 	config->filename = talloc_strdup (config, notmuch_config_env);
+    } else if ((notmuch_config_env = getenv ("XDG_CONFIG_HOME"))) {
+	config->filename = talloc_strdup (config, notmuch_config_env);
     } else {
-	config->filename = talloc_asprintf (config, "%s/.notmuch-config",
+	config->filename = talloc_asprintf (config, "%s/.config/notmuch/config",
 					    getenv ("HOME"));
     }
 
-- 
2.16.2

[PATCH 2/2] doc: reflect config default location change

[sh!zeeg]

---
 doc/man1/notmuch-compact.rst | 2 +-
 doc/man1/notmuch-config.rst  | 2 +-
 doc/man1/notmuch-reply.rst   | 2 +-
 doc/man1/notmuch.rst         | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/man1/notmuch-compact.rst b/doc/man1/notmuch-compact.rst
index b05593ec..98de622f 100644
--- a/doc/man1/notmuch-compact.rst
+++ b/doc/man1/notmuch-compact.rst
@@ -41,7 +41,7 @@ of notmuch.
 
 **NOTMUCH\_CONFIG**
     Specifies the location of the notmuch configuration file. Notmuch
-    will use ${HOME}/.notmuch-config if this variable is not set.
+    will use ${XDG_CONFIG_HOME}/notmuch/config if this variable is not set.
 
 SEE ALSO
 ========
diff --git a/doc/man1/notmuch-config.rst b/doc/man1/notmuch-config.rst
index 89909808..aeedc18a 100644
--- a/doc/man1/notmuch-config.rst
+++ b/doc/man1/notmuch-config.rst
@@ -213,7 +213,7 @@ of notmuch.
 
 **NOTMUCH\_CONFIG**
     Specifies the location of the notmuch configuration file. Notmuch
-    will use ${HOME}/.notmuch-config if this variable is not set.
+    will use ${XDG_CONFIG_HOME}/notmuch/config if this variable is not set.
 
 SEE ALSO
 ========
diff --git a/doc/man1/notmuch-reply.rst b/doc/man1/notmuch-reply.rst
index c893ba04..b593ed9f 100644
--- a/doc/man1/notmuch-reply.rst
+++ b/doc/man1/notmuch-reply.rst
@@ -19,7 +19,7 @@ Reply-to: header is present and different from any To:/Cc: address it
 is used, otherwise From: header is used. Unless
 ``--reply-to=sender`` is specified, values from the To: and Cc: headers
 are copied, but not including any of the current user's email addresses
-(as configured in primary\_mail or other\_email in the .notmuch-config
+(as configured in primary\_mail or other\_email in the ${NOTMUCH\_CONFIG}
 file) in the recipient list.
 
 It also builds a suitable new subject, including Re: at the front (if
diff --git a/doc/man1/notmuch.rst b/doc/man1/notmuch.rst
index d2cd8da5..e9a4b6ca 100644
--- a/doc/man1/notmuch.rst
+++ b/doc/man1/notmuch.rst
@@ -74,7 +74,7 @@ The setup command will prompt for your full name, your primary email
 address, any alternate email addresses you use, and the directory
 containing your email archives. Your answers will be written to a
 configuration file in ${NOTMUCH\_CONFIG} (if set) or
-${HOME}/.notmuch-config . This configuration file will be created with
+${XDG_CONFIG_HOME}/notmuch/config . This configuration file will be created with
 descriptive comments, making it easy to edit by hand later to change the
 configuration. Or you can run **notmuch setup** again to change the
 configuration.
-- 
2.16.2

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

[Tomi Ollila]

On Wed, Mar 14 2018, shizeeque@gmail.com wrote:

> According to XDG Base Directory Specification
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> configuration files should be stored in $XDG_CONFIG_HOME which
> defaulted to $HOME/.config/

Interesting stuff -- IIRC we tried something like this like 5 years ago
... and now we've been discussing about other options ...

Anyway, this would break status quo and current users' environments,
and secondly it looks like all fails unless this /notmuch/ directory
in XDG_CONFIG_HOME / ~/.config exists.

Tomi


> ---
>  notmuch-config.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/notmuch-config.c b/notmuch-config.c
> index e1b16609..7651c912 100644
> --- a/notmuch-config.c
> +++ b/notmuch-config.c
> @@ -293,7 +293,7 @@ out:
>  /* Open the named notmuch configuration file. If the filename is NULL,
>   * the value of the environment variable $NOTMUCH_CONFIG will be used.
>   * If $NOTMUCH_CONFIG is unset, the default configuration file
> - * ($HOME/.notmuch-config) will be used.
> + * ($XDG_CONFIG_HOME/notmuch/config) will be used.
>   *
>   * If any error occurs, (out of memory, or a permission-denied error,
>   * etc.), this function will print a message to stderr and return
> @@ -358,8 +358,10 @@ notmuch_config_open (void *ctx,
>  	config->filename = talloc_strdup (config, filename);
>      } else if ((notmuch_config_env = getenv ("NOTMUCH_CONFIG"))) {
>  	config->filename = talloc_strdup (config, notmuch_config_env);
> +    } else if ((notmuch_config_env = getenv ("XDG_CONFIG_HOME"))) {
> +	config->filename = talloc_strdup (config, notmuch_config_env);
>      } else {
> -	config->filename = talloc_asprintf (config, "%s/.notmuch-config",
> +	config->filename = talloc_asprintf (config, "%s/.config/notmuch/config",
>  					    getenv ("HOME"));
>      }
>  
> -- 
> 2.16.2

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

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> Interesting stuff -- IIRC we tried something like this like 5 years ago
> ... and now we've been discussing about other options ...

Yes, several more radical changes have been proposed. This series
(modulo issues Tomi points out) is relatively minor so we could probably
entertain some version of it while we think about the harder issues
related to configuration stored in the database.

> Anyway, this would break status quo and current users' environments,
> and secondly it looks like all fails unless this /notmuch/ directory
> in XDG_CONFIG_HOME / ~/.config exists.

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.

d

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

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

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

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.

           --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[David Bremner]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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.

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

[Jani Nikula]

On Thu, 15 Mar 2018, Daniel Kahn Gillmor <dkg@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.