Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
![](https://secure.gravatar.com/avatar/1786350e8a814c84a91563c7c11e4000.jpg?s=120&d=mm&r=g)
On Fri, 30 May 2014 18:12:18 +0530 Rajeev S <rajeevs1992@gmail.com> wrote:
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 inrm -f
?)
No, as I think, --yes
and --force
or -f
have different use cases.
For conformations --yes
is used most of the times, it says 'hey I
know you are going to ask this question and my answer would be yes'.
While --force
is to actually *force* any operation that cannot be
completed otherwise.
About the create domain suggestion, Is the follow up question on
*create domain*
, upon missing domain, such a bad idea? A user already canadd 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 list@domain.org <list@domain.org>* *$./mmclient create list user@gmail.com <user@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.
Good to hear that. Did you give TDD a try?
Also, I would like to ask how the tests should be triggered. Should there be a
mmclient test
with a set of possible switches likeall
,domain
,list
,user
etc? Or should the customarypython setup.py test
be used?
You can use nose2
for that, like mailman does. It automatically
discovers all the tests in directories specified and runs them.
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.
What detail profile are you talking about? Apart from addresses and
name(optional) does mailman store any other data about a user? You can
show the lists he is subscribed to, but describe user
may not be an
appropriate command for that. Maybe you can add it in users scope
itself like
mmclient user a@b.org --list-subscriptions
Others may have different thoughts though.
-- thanks, Abhilash Raj
![](https://secure.gravatar.com/avatar/be5f8c502683e4e5eb7d060b04ce1b4a.jpg?s=120&d=mm&r=g)
On Friday 30 May 2014 07:09 PM, Abhilash Raj wrote:
On Fri, 30 May 2014 18:12:18 +0530 Rajeev S <rajeevs1992@gmail.com> wrote:
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 inrm -f
?) No, as I think,--yes
and--force
or-f
have different use cases. For conformations--yes
is used most of the times, it says 'hey I know you are going to ask this question and my answer would be yes'. While--force
is to actually *force* any operation that cannot be completed otherwise.
Ok. I will go with the --yes.
Good to hear that. Did you give TDD a try?
Not yet, I wrote a few test cases for the existing units using python untitest.
I will try to focus on following TDD for the next set of units.
Also, I would like to ask how the tests should be triggered. Should there be a
mmclient test
with a set of possible switches likeall
,domain
,list
,user
etc? Or should the customarypython setup.py test
be used? You can usenose2
for that, like mailman does. It automatically discovers all the tests in directories specified and runs them.
Ok.
What detail profile are you talking about? Apart from addresses and name(optional) does mailman store any other data about a user? You can show the lists he is subscribed to, but
describe user
may not be an appropriate command for that. Maybe you can add it in users scope itself likemmclient user a@b.org --list-subscriptions
Others may have different thoughts though.
The following are the details that are available for a user
1.Addresses 2. Subscriptions (3. Subscription list id's) 4.Preferences 5.Self link
@all BTW I have pushed r55.
http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/...
participants (2)
-
Abhilash Raj
-
Rajeev S