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

[Stephen J. Turnbull]

BTW, unless specifically mentioned that I'm speaking as mentor, I'm
speaking as an ordinary developer, and you should feel free to argue
with me, or agree with me, or reserve comment until you feel
comfortable discussing issues.  Also, I apologize if I end up talking
"down" to you.  I don't know you very well yet, so feel free to let me
know you already understand what I'm talking about.

Rajeev S writes:

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

Sure, I'm just saying that argparse "likes" to associate "positional"
with "required", and keyword-like with "optional".  We should consider
carefully whether we want to deviate from that practice because
there's probably good reason for it.

 > In my opinion, I don't like the `one level of sub command`

That's fine by me, and as your mentor I advise that you continue to
discuss this with Barry.  I hope that you and he will come to
agreement on this point.  In the end, however, Barry is The Client,
and if you don't come to a meeting of minds the default is to do it
his way.  OK?

Taking my mentor hat off, now.

 > Further there is a possibility of the user specifying multiple scopes,
 > 
 > mmclient show --list --listname "list at domain.org" --domain

I think this is a syntax error, and should be reported that way.

 > > 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.

I agree with that.  Note, however, that it has been suggested that in
the shell it should be possible to

   >>> set scope list=foo-list at domain.org

so that after that only list-scope commands are allowed and only
foo-list will be affected.

 > 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.

Again speaking as mentor, I would not call it a "mistake" in your
case, but rather say it is up to your personal preference.  You have
demonstrated that you do write code that can be refactored and that
you refactor spontaneously.  It's acceptable for developers to "write
code for discussion" to the extent that they are comfortable with such
refactoring.  Many clients will find that a great convenience (it's a
simple form of "prototype").

Conversely it's unacceptable for you to respond to The Client's
requirements by saying "I've already written the code and it doesn't
do that."  (Except, of course, if the existing code was written to a
specification accepted by the client and he's changing his mind.  Then
both sides have a responsibility to negotiate.)

 > 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.

Wearing my developer hat, I don't much like an implicit default
scope.  The user should either specify the scope in each command, or
explicitly specify a default scope.

Regards,
Steve