Hi, I have made more additions to the CLI, like the `delete` command and the `user` scope.
Following is the list of changes brought about 1.Introduce User scope Actions supported by User scope currently are create, show and delete. show users, like other scopes, supports verbose and no-header flags. However the detailed listing of users is not quite effective as most of the fields are lists rather than single valued attributes. The non detailed version prints one of the email ids of each user. The show list command takes an optional argument list name that gives the users who are members of the list. 2.Introduce a cli/lib directory, to store procedures common across the application. The directory is to hold the procedures and classes that are reused among scripts. It currently holds a class that is used to colorize the output printed on the terminal. 3.Updated and improved docs/using.txt. It was obsolete in r54. 4.Added delete action for all objects The action is confirmed by a question to user, which can be overridden by a --yes switch. I will be committing and pushing r55 tonight (30/05/2014 around 16:30 UST, I am away from the computer right now). ____ As mentioned by Steve and agreed by Barry, I too believe that, in the scenario of the CLI multiple confirmations won't be necessary. In a situation in which such multiple confirmations come necessary, I believe that the commands will be better if the confirmations are replaced by switches. I agree that an override for the confirmation message is necessary so that the CLI commands can be used in scripts and I would like to follow Barry's suggestion of using a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in `rm -f` ?) About the create domain suggestion, Is the follow up question on `*create domain*`, upon missing domain, such a bad idea? A user already can `add a domain` by using the web interface. If that is not ambiguous, neither is this, right? However I see this issue, if a newbie user types in an email address in place of the list name, probably on misreading the command format, he would end up creating a domain for his mail provider. *$./mmclient create list --help* *Creates the list l...@domain.org <l...@domain.org>* *$./mmclient create list u...@gmail.com <u...@gmail.com>* *The domain gmail.com <http://gmail.com> does not exist.Create one?[y/n] y* *$* @Abhilash I have written unittests for methods like connect and create, but have to refine them more. Hence the tests won't come up in this revision. Also, I would like to ask how the tests should be triggered. Should there be a `mmclient test` with a set of possible switches like `all` ,`domain`, `list`, `user` etc? Or should the customary `python setup.py test` be used? I also propose to build a a *`describe user`* command that gives a detailed profile of the user. Verbose listing using tables is not so effective users as most of the attributes are lists. Thanks! _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
