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
On Thu, 29 May 2014 22:30:25 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Also maybe you can try making your tool a little more smart? Like lets
say I try to create a list abhil...@raj.com and there is no domain
raj.com in the database, so instead of just showing error maybe
On Fri, 30 May 2014 18:12:18 +0530
Rajeev S rajeevs1...@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
On Fri, 30 May 2014 18:12:18 +0530
Rajeev S rajeevs1...@gmail.com wrote:
When you are not citing any context from previous posts, you should
start a new thread instead of re-posting on same old one. It makes it
difficult to find a specific post with this long thread.
--
thanks,
Abhilash Raj
On Friday 30 May 2014 07:09 PM, Abhilash Raj wrote:
On Fri, 30 May 2014 18:12:18 +0530
Rajeev S rajeevs1...@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
Hi Barry,
Although I haven't had time to go through the code, I'm liking what I'm
seeing
here on the mailing list. Just a quick comment.
[...]
Ideally, because this is a command line tool aimed and users, there should
be
a manpage for mmclient. Fortunately, it's *really* easy to write
Rajeev S writes:
Also maybe you can try making your tool a little more smart? Like lets
say I try to create a list abhil...@raj.com and there is no domain
raj.com in the database, so instead of just showing error maybe you can
ask the user:
The domain raj.com does not exist, Do
* Stephen J. Turnbull step...@xemacs.org:
Rajeev S writes:
Also maybe you can try making your tool a little more smart? Like lets
say I try to create a list abhil...@raj.com and there is no domain
raj.com in the database, so instead of just showing error maybe you can
ask the
On May 29, 2014, at 05:20 PM, Patrick Ben Koetter wrote:
Deleting a list/domain requires an (internal) scheduler. Does Mailman have
one? A broom job that can be called via cron?
Sort of, but the way these are handled currently are individual scripts that
each have to be added to cron.
... and
Patrick Ben Koetter writes:
I doubt anyone that igorant of e-mail and how it works will ever
make it to the MM3 command line client, but yes, such cases do
exist.
I think they're actually likely to be reasonably common.
However I think the use case prepare Mailman to handle mail for a
On May 30, 2014, at 03:41 AM, Stephen J. Turnbull wrote:
Probably scripts should not be using commands that need multiple
confirmations, though.
Agreed!
-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
* Stephen J. Turnbull step...@xemacs.org:
Patrick Ben Koetter writes:
I doubt anyone that igorant of e-mail and how it works will ever
make it to the MM3 command line client, but yes, such cases do
exist.
I think they're actually likely to be reasonably common.
However I think
Although I haven't had time to go through the code, I'm liking what I'm seeing
here on the mailing list. Just a quick comment.
On May 27, 2014, at 12:27 PM, Abhilash Raj wrote:
Since this tool is meant for the users, you should write better
documentation. Like in using.txt
Ideally, because
On May 14, 2014, at 12:19 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
I just want it to be consistent, easily described, and easily understood by
users. If it makes sense for the mmclient CLI to different from the
shell-access mailman command, then we at least need to be
Rajeev S rajeevs1...@gmail.com wrote:
As discussed, I have completed the r54, that does the following
1. The arguments will be specified as positional arguments
wherever necessary and possible. The ideal way to use
positional arguments here is if the argument to the command
is the name of
On Tuesday 27 May 2014 12:27 PM, Abhilash Raj wrote:
Rajeev S rajeevs1...@gmail.com wrote:
Both of these options looks clean to me as a user. So if I am right you
have completed
* Listing of domains
* Listing of mailing lists(filtered by domain also)
* Creating domains
* Creating mailing
As discussed, I have completed the r54, that does the following
1. The arguments will be specified as positional arguments
wherever necessary and possible. The ideal way to use
positional arguments here is if the argument to the command
is the name of an instance the scope, use positional args
Hi,
I have pushed the revision 53, that has the following changes.
1. Refactoring as mentioned in the comments by Steve
2. Grouping of options and sub commands using subparsers
3. Changed the format of the command from *mmclient scope action*
to *mmclient action scope*
4. Replaced ambiguous
On Tuesday 13 May 2014 07:12 PM, Barry Warsaw wrote:
On May 13, 2014, at 03:27 PM, Rajeev S wrote:
Would --list be implied by seeing a `--listname=l...@example.com`? E.g. would
this be just as useful, and a little shorter:
mmclient show --listname=l...@example.com --domain=example.org
?
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
On Monday 12 May 2014 09:12 PM, Barry Warsaw wrote:
A better name might be `show` since the term list is so overloaded in this
context. Here's it's being used as a verb and a noun to refer to different
concepts, and I think that's confusing.
Yes, its confusing. In fact, I was looking for a
On May 13, 2014, at 01:45 AM, Stephen J. Turnbull wrote:
In the model Rajeev has shown so far, the scope argument (list,
domain, user) hasn't been optional.
If it's truly non-optional in the sense that there's no default, and the scope
is required, then maybe it's okay. It just doesn't look
On May 13, 2014, at 03:27 PM, Rajeev S wrote:
Further there is a possibility of the user specifying multiple scopes,
mmclient show --list --listname l...@domain.org --domain
Would --list be implied by seeing a `--listname=l...@example.com`? E.g. would
this be just as useful, and a little
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
On May 11, 2014, at 10:37 PM, Rajeev S wrote:
I doubt the usability of a common option `name`. As per the above snippet,
you have used a `in-domain` to specify the domain name. There are many such
instances where you would have to use more than one `name`, for instance
adding moderators for a
On May 11, 2014, at 10:37 PM, Rajeev S wrote:
I have modified the CLI to use English like commands and hence will
use them hereafter.
*list*
The command lists the entities and should be available for users,mailing
lists and domains.
mmclient list list [l...@domain.org] [-v for verbose]
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
Hi,
I have elaborated the implementation and the motivations behind the
current approach in the following blog post, in case it might help
reviewing the code better.
http://myfossblog.blogspot.in/2014/05/lets-talk-over-cup-of-code.html
___
Hi,
I have added two more methods, *create domain* and *list mailing lists*.
The listing feature is performed using the `tabulate` module, which I have
added to the install_requires.
Also, the usage of the CLI is explained in the cli/docs/using.txt.
*Regards,Rajeev S*
*Government Engineering
On Sat, May 3, 2014 at 2:49 AM, Rajeev S rajeevs1...@gmail.com wrote:
Hi,
I have added two more methods, *create domain* and *list mailing lists*.
I haven't watched this entire thread, but I hope someone is
considering setting appropriate defaults for at least two mailing list
types such as:
Rajeev S writes:
Hi,
I have added two more methods, *create domain* and *list mailing lists*.
The listing feature is performed using the `tabulate` module, which I have
added to the install_requires.
Also, the usage of the CLI is explained in the cli/docs/using.txt.
Great!
I have
Tom Browder writes:
I haven't watched this entire thread, but I hope someone is
considering setting appropriate defaults for at least two mailing list
types such as:
read-only (news)
read-post (moderated or not)
Not in that terminology, no. What do you hope to type, and what
On Sat, May 3, 2014 at 8:44 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Tom Browder writes:
I haven't watched this entire thread, but I hope someone is
considering setting appropriate defaults for at least two mailing list
types such as:
read-only (news)
read-post
Tom Browder writes:
I think this GSoC project might be the place to at least start with
the option of choosing a list style such as a defined read-only
mailing list.
Ah, OK, I see what you're getting at now.
I think this is out of scope for the CLI project, although it's
possible that
On May 03, 2014, at 09:59 AM, Tom Browder wrote:
Using the latest cli commands as shown in Rajeev's
/src/mailmanclient/cli/docs/using.txt would be for the default list
style:
test_one = example.create_list('test-one')
Then, for other styles, we could use something like (pardon my pseudo
On Sat, May 3, 2014 at 12:21 PM, Barry Warsaw ba...@list.org wrote:
On May 03, 2014, at 09:59 AM, Tom Browder wrote:
...
Then, for other styles, we could use something like (pardon my pseudo code):
test_one = example.create_list('test-one', style='read-only')
...
The CLI (i.e. `mailman
Stephen J. Turnbull wrote:
Ah, OK, I see what you're getting at now.
I think this is out of scope for the CLI project, although it's
possible that providing some kind of scriptable interface (even a
simple way to store a sequence of commands acting on the current
list should suffice, where
Hi,
I have added the licensing blocks to the files and pushed the code.
*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk http://rajeevs.tk*
On Fri, May 2, 2014 at 7:13 AM, Barry Warsaw ba...@list.org wrote:
On May 02, 2014, at 06:36 AM, Rajeev S wrote:
3.The
Hi,
I will be using the following branch for the Mailman CLI project
*https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli
https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli*
I have created and committed the basic structure of the project in the
branch.Also, as the
On May 02, 2014, at 06:36 AM, Rajeev S wrote:
3.The code has been verified with pep8 *and* flake8 tools. It also passes
most of the guidelines mentioned in Barry's styleguide. Some of the
guidelines are yet to be met, like the licensing block
and stuff like __all__. Also the ^L at major sections
40 matches
Mail list logo
