From b394a8fe505d8481f85f6f3f3e9d042e50bb0a7a Mon Sep 17 00:00:00 2001 From: David Bremner Date: Thu, 9 Apr 2015 08:53:56 +0900 Subject: [PATCH] Re: argument parsing refactoring round3 --- 5f/2632e145c41dc6de744f4b7c1ca912fda35e41 | 119 ++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 5f/2632e145c41dc6de744f4b7c1ca912fda35e41 diff --git a/5f/2632e145c41dc6de744f4b7c1ca912fda35e41 b/5f/2632e145c41dc6de744f4b7c1ca912fda35e41 new file mode 100644 index 000000000..03891b729 --- /dev/null +++ b/5f/2632e145c41dc6de744f4b7c1ca912fda35e41 @@ -0,0 +1,119 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id 21C1D6DE1625 + for ; Wed, 8 Apr 2015 16:56:23 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: 0.389 +X-Spam-Level: +X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[AWL=0.389] + autolearn=disabled +Received: from arlo.cworth.org ([127.0.0.1]) + by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 9TNm5lY5n7hz for ; + Wed, 8 Apr 2015 16:56:21 -0700 (PDT) +Received: from mx.xen14.node3324.gplhost.com (gitolite.debian.net + [87.98.215.224]) + by arlo.cworth.org (Postfix) with ESMTPS id B5D6E6DE1552 + for ; Wed, 8 Apr 2015 16:56:20 -0700 (PDT) +Received: from remotemail by mx.xen14.node3324.gplhost.com with local (Exim + 4.80) (envelope-from ) + id 1YfznS-0006nL-B7; Wed, 08 Apr 2015 23:54:14 +0000 +Received: (nullmailer pid 30875 invoked by uid 1000); Wed, 08 Apr 2015 + 23:53:56 -0000 +From: David Bremner +To: guyzmo +Subject: Re: argument parsing refactoring round3 +In-Reply-To: <20150408143147.GD5218@vilya.online.net> +References: <871tjws8w8.fsf@qmul.ac.uk> + <1428435042-16503-1-git-send-email-david@tethera.net> + <20150408143147.GD5218@vilya.online.net> +User-Agent: Notmuch/0.19+96~g703c8f9 (http://notmuchmail.org) Emacs/24.4.1 + (x86_64-pc-linux-gnu) +Date: Thu, 09 Apr 2015 08:53:56 +0900 +Message-ID: <87oamy41nv.fsf@maritornes.cs.unb.ca> +MIME-Version: 1.0 +Content-Type: text/plain +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.18 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Wed, 08 Apr 2015 23:56:23 -0000 + +guyzmo writes: + +> Hi David, + +[...] + +> I see you patching and repatching notmuch's CLI to improve it, and I was +> wondering whether you had considered actually using `docopt` to generate +> the CLI parser from the output. +> +> It's possible to chain docopts to create a CLI UI very much alike the +> git command, and it's more easily maintainable, as you're actually +> generating the code from the `--help` page instead of the other way +> around, making you focus on how you want the user to use the CLI only. + +[...] + +> what do you believe? + +It's an interesting idea, and if I was faced with writing CLI parser +from scratch (i.e. 4 years ago) I would investigate it more seriously. +As it stands, I'm not particularly annoyed with the notmuch argument +parsing code, so I mainly see negative issues about your proposal. + +- I'm not sure how much this change would ripple through the rest of the + notmuch code. At least all of the variables set by the current + argument parsing code would have to be set foo=args.foo, or replaced + everywhere with args.foo. + +- It would require modifying the notmuch CLI to conform to the + conventions of docopt. Of course, you might consider this a feature, + but I think as many people would be annoyed as would be happy. + +- The most dramatic example of an appartently missing feature from + docopt is keyword arguments of the form + + --output=(messages|threads|summary). + + These are the reason we rolled our own parser in the first place, + rather than using e.g. gnu getopt. docopt says it doesn't do data + validation, which is fine philosophically, but by the time we add back + in validation code, I'm not sure we win very much in the + maintainability department. + +- I don't really know about the health of the docopt.c project, compared + to the python version. It seems somewhat unfinished [1]; in particular + a lack of positional arguments seems like a showstopper for us. + arguments. There has never been a release (which is the norm for + github, but not for dependencies of notmuch), and the last commit was + in December of 2014. + +- Since docopt_c_py is not widely in distros (it isn't in Debian, for + example), we'd have to emded it the notmuch source. It's only 217 + lines of fairly simple python, but embedding 3rd party code is + something we try pretty hard to avoid. + +As always, my lack of enthusiasm doesn't prevent someone else from +investigating further, but hopefully the points I listed above give +anyone doing such investigation some hints as to what I (and I suspect +not just I) would object to about any hypothetical patches. + +David + +[1]: From the README.md "Note, at this point the code generator handles +only options (positional arguments, commands and pattern matching will +follow)." -- 2.26.2