From: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>
To: David Bremner <david@tethera.net>
Cc: notmuch@notmuchmail.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`
Date: Wed, 29 Apr 2020 18:59:13 +0300 [thread overview]
Message-ID: <CA+Tk8fxDTPHJATotNXRJH3u-YnFprE0H_GR-s8esjjT=kNG=_Q@mail.gmail.com> (raw)
In-Reply-To: <87pnbql2sg.fsf@tethera.net>
On Wed, Apr 29, 2020 at 6:39 PM David Bremner <david@tethera.net> wrote:
> I guess I'm a bit leery of removing UI features that presumably at least
> some people rely on. It's pretty upsetting to have sofware break one's
> muscle memory.
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". :)
However, even with my `--strict` argument, I was perhaps leaning
toward adding a more API-friendly command line parser, that would
basically only take arguments in the form `--flag=value`, anything
else being considered a search term, and anything not a flag but
before a single `--` should be considered an error.
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`.
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.
Ciprian.
next prev parent reply other threads:[~2020-04-29 15:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 12:53 Inconsistencies in handling command flags: `--flag=value` different than `--flag value` Ciprian Dorin Craciun
2020-04-27 17:53 ` David Bremner
2020-04-27 18:02 ` Daniel Kahn Gillmor
2020-04-27 18:20 ` Tomi Ollila
2020-04-27 19:21 ` Ciprian Dorin Craciun
2020-04-29 2:16 ` Daniel Kahn Gillmor
2020-04-29 14:18 ` Tomi Ollila
2020-04-29 15:39 ` David Bremner
2020-04-29 15:45 ` Jameson Graef Rollins
2020-04-29 16:28 ` David Bremner
2020-05-05 18:28 ` Carl Worth
2020-05-07 19:26 ` [PATCH] notmuch(1): clarify documentation about --option/value separators Daniel Kahn Gillmor
2020-05-07 23:40 ` Carl Worth
2020-05-08 12:01 ` David Bremner
2020-05-08 16:06 ` Daniel Kahn Gillmor
2020-04-29 15:59 ` Ciprian Dorin Craciun [this message]
2020-04-29 16:07 ` Inconsistencies in handling command flags: `--flag=value` different than `--flag value` Jameson Graef Rollins
2020-04-29 15:33 ` Jameson Graef Rollins
2020-04-30 16:59 ` Daniel Kahn Gillmor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+Tk8fxDTPHJATotNXRJH3u-YnFprE0H_GR-s8esjjT=kNG=_Q@mail.gmail.com' \
--to=ciprian.craciun@gmail.com \
--cc=david@tethera.net \
--cc=dkg@fifthhorseman.net \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).