[Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Stephen J. Turnbull]

Rajeev S writes:
 > Hi Abhilash,

Please don't top-post.  It's very helpful to readers to keep the
"subthreads" about particular issues separate, while at the same time
bundling them together for ease of mail-handling.

 > I did not quite get the user role part.A command line utility runs on the
 > server on which a software instance runs, just like a MySQL command line
 > utility.You will need physical access to the system or atleast the shell.I
 > believe you cannot expect every moderator of the list to have that kind of
 > access. From my point of view, the tool will be used by the list owner or
 > the server admin, just like the MySQL shell,which can be used only if you
 > have access to system shell.However, User/Role management can be imposed by
 > including a login for the shell,if necessary.Again,that's not possible for
 > the command tools.

Why not?  The CLI tools will have access to the user database, so in
theory you could authenticate.  In *practice*, this may be outside of
the scope of your project because there's no provision for
authentication in the current RESTful interface; you end up
restricting to connections from localhost.

But by the same token, past projects have decided to connect to
Postorius rather than Mailman itself precisely because Postorious
*does* maintain roles and credentials for users.  Again, probably
beyond the scope of your project, but for precisely this reason it has
been proposed a few times that the authn/authz part of Postorius be
broken out into a separate module.

 > And Yes.Users will be a part of this. I prefer to build the other two
 > first.Many methods that can come under User class is better suited under
 > the other two.For eg, for adding a moderator to the list, you can do, *list
 > --addmoderator user_id , *which should be under the List class*. *But the
 > same from user point of view, would  be a complicated and less intuitive
 > command, *user **user_id **--addmoderator **--list list_id *. So, after the
 > list and domain functions are built, It will be more clear what the user
 > class must do.

I agree with your logic here.

But I find the text very difficult to read.  There should be at least
one space after a sentence-ending period ("Yes.Users" looks like a
class attribute!)  And I have no idea what the semantics of "*" is
intended to be.

 > About optparse, I actually meant argparse,sorry about that :). And thanks
 > for the style guide tip.

Despite the current thread on python-dev<wink target="Barry"/>, I
strongly recommend the pep8.py tool (available on PyPI as well as
upstream: https://github.com/jcrocholl/pep8/).  pyflakes, pylint, and
pychecker are also good tools, but their orientation is a bit
different, and you may or may not find them useful (and in particular
you may find after a while that you *never* get warnings from them).