5f/2632e145c41dc6de744f4b7c1ca912fda35e41

   1 Return-Path: <david@tethera.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id 21C1D6DE1625\r
   6  for <notmuch@notmuchmail.org>; Wed,  8 Apr 2015 16:56:23 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.389\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[AWL=0.389]\r
  12  autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id 9TNm5lY5n7hz for <notmuch@notmuchmail.org>;\r
  16  Wed,  8 Apr 2015 16:56:21 -0700 (PDT)\r
  17 Received: from mx.xen14.node3324.gplhost.com (gitolite.debian.net\r
  18  [87.98.215.224])\r
  19  by arlo.cworth.org (Postfix) with ESMTPS id B5D6E6DE1552\r
  20  for <notmuch@notmuchmail.org>; Wed,  8 Apr 2015 16:56:20 -0700 (PDT)\r
  21 Received: from remotemail by mx.xen14.node3324.gplhost.com with local (Exim\r
  22  4.80) (envelope-from <david@tethera.net>)\r
  23  id 1YfznS-0006nL-B7; Wed, 08 Apr 2015 23:54:14 +0000\r
  24 Received: (nullmailer pid 30875 invoked by uid 1000); Wed, 08 Apr 2015\r
  25  23:53:56 -0000\r
  26 From: David Bremner <david@tethera.net>\r
  27 To: guyzmo <guyzmo+notmuch@m0g.net>\r
  28 Subject: Re: argument parsing refactoring round3\r
  29 In-Reply-To: <20150408143147.GD5218@vilya.online.net>\r
  30 References: <871tjws8w8.fsf@qmul.ac.uk>\r
  31  <1428435042-16503-1-git-send-email-david@tethera.net>\r
  32  <20150408143147.GD5218@vilya.online.net>\r
  33 User-Agent: Notmuch/0.19+96~g703c8f9 (http://notmuchmail.org) Emacs/24.4.1\r
  34  (x86_64-pc-linux-gnu)\r
  35 Date: Thu, 09 Apr 2015 08:53:56 +0900\r
  36 Message-ID: <87oamy41nv.fsf@maritornes.cs.unb.ca>\r
  37 MIME-Version: 1.0\r
  38 Content-Type: text/plain\r
  39 Cc: notmuch@notmuchmail.org\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.18\r
  42 Precedence: list\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44  <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  46  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Wed, 08 Apr 2015 23:56:23 -0000\r
  53 \r
  54 guyzmo <guyzmo+notmuch@m0g.net> writes:\r
  55 \r
  56 > Hi David,\r
  57 \r
  58 [...]\r
  59 \r
  60 > I see you patching and repatching notmuch's CLI to improve it, and I was\r
  61 > wondering whether you had considered actually using `docopt` to generate\r
  62 > the CLI parser from the output.\r
  63 >\r
  64 > It's possible to chain docopts to create a CLI UI very much alike the\r
  65 > git command, and it's more easily maintainable, as you're actually\r
  66 > generating the code from the `--help` page instead of the other way\r
  67 > around, making you focus on how you want the user to use the CLI only.\r
  68 \r
  69 [...]\r
  70 \r
  71 > what do you believe?\r
  72 \r
  73 It's an interesting idea, and if I was faced with writing CLI parser\r
  74 from scratch (i.e. 4 years ago) I would investigate it more seriously.\r
  75 As it stands, I'm not particularly annoyed with the notmuch argument\r
  76 parsing code, so I mainly see negative issues about your proposal.\r
  77 \r
  78 - I'm not sure how much this change would ripple through the rest of the\r
  79   notmuch code. At least all of the variables set by the current\r
  80   argument parsing code would have to be set foo=args.foo, or replaced\r
  81   everywhere with args.foo.\r
  82    \r
  83 - It would require modifying the notmuch CLI to conform to the\r
  84   conventions of docopt. Of course, you might consider this a feature,\r
  85   but I think as many people would be annoyed as would be happy.\r
  86 \r
  87 - The most dramatic example of an appartently missing feature from\r
  88   docopt is keyword arguments of the form\r
  89   \r
  90     --output=(messages|threads|summary).\r
  91 \r
  92   These are the reason we rolled our own parser in the first place,\r
  93   rather than using e.g. gnu getopt.  docopt says it doesn't do data\r
  94   validation, which is fine philosophically, but by the time we add back\r
  95   in validation code, I'm not sure we win very much in the\r
  96   maintainability department.\r
  97   \r
  98 - I don't really know about the health of the docopt.c project, compared\r
  99   to the python version. It seems somewhat unfinished [1]; in particular\r
 100   a lack of positional arguments seems like a showstopper for us.\r
 101   arguments. There has never been a release (which is the norm for\r
 102   github, but not for dependencies of notmuch), and the last commit was\r
 103   in December of 2014.\r
 104 \r
 105 - Since docopt_c_py is not widely in distros (it isn't in Debian, for\r
 106   example), we'd have to emded it the notmuch source.  It's only 217\r
 107   lines of fairly simple python, but embedding 3rd party code is\r
 108   something we try pretty hard to avoid.\r
 109 \r
 110 As always, my lack of enthusiasm doesn't prevent someone else from\r
 111 investigating further, but hopefully the points I listed above give\r
 112 anyone doing such investigation some hints as to what I (and I suspect\r
 113 not just I) would object to about any hypothetical patches.\r
 114 \r
 115 David\r
 116 \r
 117 [1]: From the README.md "Note, at this point the code generator handles\r
 118 only options (positional arguments, commands and pattern matching will\r
 119 follow)."\r