Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

[Jameson Graef Rollins]

On Wed, Apr 29 2020, Ciprian Dorin Craciun <ciprian.craciun at gmail.com> wrote:
> I think there are two complete different use-cases for the `notmuch` binary:
> * a simple CLI to query the database, in which case the current flags seem OK;
> * a "poor-mans" API to query the database, more bellow;
>
> (I know there already exists an `libnotmuch` API accessible in many
> programming languages.  However for prototyping, and even for safety
> and robustness, when performance isn't an issue, I find the tool-based
> approach much more resilient.)
>
> Now about the "API" use-case,  I assume that at the moment many users
> have already integrated `notmuch` as it is with the current flags and
> behaviour.  Thus I agree that changing any flags in backward
> incompatible way would make a lot of people unhappy, and will generate
> perhaps quite a bit of "customer support".  :)

This is a good point.  The CLI might be "poor", but important apps like
notmuch-emacs are using them, so we should be careful about changing the
interface.

> Regarding the `--boolean` vs `--no-boolean` it does solve the
> strictness problem, however it makes the life of script developers
> quite hard, as now he has a `case` or `if/then/else`.  Therefore I
> would say that `--flag=value` is the best option as it can be simply
> written as `--flag={FLAG:-true}` or in Python for example `"--flag=%s"
> % _flag`.

Also a good point.  I guess the --flag=value interface is a safer/easier
one to converge on.

> Thinking even further uppon this, perhaps an even simpler idea would
> be to provide a new command, like for example `notmuch api` that takes
> on `stdin` a JSON with a specific format and does its job.

This actually sounds like a pretty good idea...

jamie.