[Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Rajeev S]

On Monday 12 May 2014 10:15 PM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>   > Also as a general rule, I think we want just one level of
>   > subcommand, so that `mmclient show --list` would be the template.
>   > (That's open to discussion.)
>
> I wonder about this in the context of argparse and the command line,
> because argparse makes a strong distinction (and corresponding
> associations) between *required positional* arguments and *optional*
> keyword-like arguments (ie, any argument with leading dashes).

Positional arguments *can be made* optional, also be supplied
with a default value, in case the argument was not specified.

In my opinion, I don't like the `one level of sub command` as
neither the user nor the developer is benefited of such a design.
The user ends up typing the same strings as before plus an extra
`--` followed by the same set of arguments.

And from the angle of implementation, each of the *scope* name
would require a different optional argument, followed by a set of
if-else's to land at the right *scope* to manage.

Further there is a possibility of the user specifying multiple scopes,

mmclient show --list --listname "list at domain.org" --domain

which makes the outcome dependent on the order in which the
if-else's are written. This is a serious bug when actions like `delete`
are being used.

> In the model Rajeev has shown so far, the "scope" argument (list,
> domain, user) hasn't been optional.

I assumed this model was OK since I had received no comments
against that part, since the beginning. I strongly believe that it is quite
effective to mention the scope this way.

>   > mmclient set --key <name> --value <value>
>
> This seems unnecessarily verbose on the one hand, and to not actually
> correspond to an actual use case, on the other: there's no scope
> mentioned.  I feel the scope should be mandatory, even if it's
> sitewide:
>
>      mmclient set --site-wide --key CAN_PERSONALIZE --value No
>      mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes
>
> (after the first one, the second would be an error, I guess, but in
> other cases a site-wide setting would be interpreted as a default).

Got a bit confused with the use of *scope* in this context.
Anyways, if the scope is not specified, apply the setting on a
default *scope*, `default=site-wide` makes sense, while others
do not.

> I guess this horse has already bolted the barn, but I wonder about a
> syntax like
>
>      mmclient set --site-wide --key PERSONALIZE --value Permitted
>      mmclient set --domain=python.org --key PERSONALIZE --value Permitted
>      mmclient set --list=mailman-users at python.org --key PERSONALIZE --value No
>
> for resource constraining settings.  (Permitted could probably be an
> alias for False.)


Sorry about the horse :). As I said, I assumed it was OK, and It was a
mistake from my part not to discuss the command syntax before
working on it.

Also, the above is still possible with the current version. The *scope* 
positional argument can
be made to default to a *scope* that has no solid structure, `settings` for
example. More generally, it could be defaulted to a `general` scope, managed
by a `General` class, that inherits from multiple classes like `Settings`,
`Backup/restore` etc.

And as the final word, I am ready to change the command style,

mmclient <action> <scope> <arguments>

if there is some serious disagreement with it.

> Steve
>
>
>