Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 you can ask the user: The domain raj.com does not exist, Do you want to create one? [y/n] I'm not sure I like this approach. Creating a domain should be a heavyweight operation, and eventually should include a bunch of sanity checks, like existence of domains and MX records. I have visions (nightmares) of users coming to us saying User: I said yes, but mail never arrives. Dev: Oh, is there a proper entry in the DNS? User: Doesn't Mailman create the domain? I agree to your point that it should be a heavyweight operation, I guess i was not able to express myself. I don't know if this CLI client can add domains to mailman(I mean add domain to mailman before and not *create*), there could be a prompt saying This mailman installation is not configured to use this domain, do you want to do it now? and then maybe it will walk the user through the usual process of adding a new domain? Or maybe it could schedule a deletion after a pre-defined time with a reasonable default lets say 1 Day? And for an urgency(to delete) there could be --force argument? Deleting a list should be immediate, but I agree it should be confirmed. -- thanks, Abhilash Raj ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 more common than --yes, as in `rm -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 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. 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 like `all` ,`domain`, `list`, `user` etc? Or should the customary `python 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 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in `rm -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 like `all` ,`domain`, `list`, `user` etc? Or should the customary `python 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. 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 like `mmclient 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/55 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 manpages in reST with Sphinx. Sure it is necessary. And writing the man page is mentioned in my proposal as a project deliverable. http://sphinx-doc.org/builders.html#sphinx.builders.manpage.ManualPageBuilder And since examples never hurt: http://tinyurl.com/pwa2dfh Thanks for the links. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 you want to create one? [y/n] I'm not sure I like this approach. Creating a domain should be a heavyweight operation, and eventually should include a bunch of sanity checks, like existence of domains and MX records. I have visions (nightmares) of users coming to us saying User: I said yes, but mail never arrives. Dev: Oh, is there a proper entry in the DNS? User: Doesn't Mailman create the domain? Or maybe it could schedule a deletion after a pre-defined time with a reasonable default lets say 1 Day? And for an urgency(to delete) there could be --force argument? Deleting a list should be immediate, but I agree it should be confirmed. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
* 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 user: The domain raj.com does not exist, Do you want to create one? [y/n] I'm not sure I like this approach. Creating a domain should be a heavyweight operation, and eventually should include a bunch of sanity checks, like existence of domains and MX records. I have visions (nightmares) of users coming to us saying User: I said yes, but mail never arrives. Dev: Oh, is there a proper entry in the DNS? User: Doesn't Mailman create the domain? 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. We should have public pillory that receives name, mail and date, whenever someone confirms the above question. ;) However I think the use case prepare Mailman to handle mail for a domain it doesn't handle mail for yet exists and we should find a way to deal with it. Perhaps we could improve this, if we used better wording that doesn't lead the operator to believe Mailman will connect a domain, setup DNS, do all the other foo and finally configure it self to handle mailing lists for that domain? Or maybe it could schedule a deletion after a pre-defined time with a reasonable default lets say 1 Day? And for an urgency(to delete) there Deleting a list/domain requires an (internal) scheduler. Does Mailman have one? A broom job that can be called via cron? could be --force argument? Deleting a list should be immediate, but I agree it should be confirmed. ... and it should be possible to pass the confirmation in the command to make it useful in scripts. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 it should be possible to pass the confirmation in the command to make it useful in scripts. Many such scripts have a --yes option to pre-confirm the action. -Barry ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 domain it doesn't handle mail for yet exists and we should find a way to deal with it. Indeed. I'm suggesting that the routine could check the DNS and a few other things, and present the list operator with a TODO list. Sortof like check_perms. Deleting a list should be immediate, but I agree it should be confirmed. ... and it should be possible to pass the confirmation in the command to make it useful in scripts. Ooh, that is a very good point. Bessides possible, the syntax for doing that should be regular. I wonder about distinguishing yes to this prompt and yes to all? Probably scripts should not be using commands that need multiple confirmations, though. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
* 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 the use case prepare Mailman to handle mail for a domain it doesn't handle mail for yet exists and we should find a way to deal with it. Indeed. I'm suggesting that the routine could check the DNS and a few other things, and present the list operator with a TODO list. Sortof like check_perms. Where would you start with the TODO list? Where would you end? Deleting a list should be immediate, but I agree it should be confirmed. ... and it should be possible to pass the confirmation in the command to make it useful in scripts. Ooh, that is a very good point. Bessides possible, the syntax for doing that should be regular. I'm hopping in on this and I certainly missed most of the discussion on the command line client: Do we have interface guidelines for commands? Shortopts, longopts, interaction, non-interactive behaviour/requirements? I wonder about distinguishing yes to this prompt and yes to all? Me too. Probably scripts should not be using commands that need multiple confirmations, though. Hmmm, Unix: Do one thing. Do it well. ? -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 this is a command line tool aimed and users, there should be a manpage for mmclient. Fortunately, it's *really* easy to write manpages in reST with Sphinx. http://sphinx-doc.org/builders.html#sphinx.builders.manpage.ManualPageBuilder And since examples never hurt: http://tinyurl.com/pwa2dfh Cheers, -Barry ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 translatable between the two. What do you mean by shell-access mailman command? src/mailman/bin/mailman.py? Yes, as much as makes sense. When installed into a virtual environment, you'll have `venv/bin/mailman` with lots of subcommands, many of which are similar to mmclient. It may not be possible to give them identical signatures, and that's fine, but it would be great if when someone learns the commands for one, the other will not break their intuition, especially for things that are close. Cheers, -Barry signature.asc Description: PGP signature ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 an instance the scope, use positional args else use optional args E.g, To filter mailing lists based on domains, do mmclient show list --domain domain.org and not mmclient show list domain.org To create a list, do mmclient create list l...@domain.org instead of mmclient create list --list list --domain domain.org 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 lists Right? Since this tool is meant for the users, you should write better documentation. Like in using.txt#39 what does long listing mean? What does `--verbose` do for listing a domain? Or even for listing all the lists? As I understand using.txt is more of a command reference than documentation? Are there only these two options for lists and domains? What about editing any list? Adding and removing user roles will be possible after you have create the `user` scope but editing of other parameters can be done? 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 you want to create one? [y/n] Just adding all the options using argparse is really not a very tough job (and with your pace, it is definitely not going to last more than one month ;-). Try to put some more thought to how you can make this tool more intuitive for the end user. 2. Added a no-header option to the detailed listing so that it becomes easier to pip the output. I will be making the following changes for r55 1.Delete Quite a straightforward one. delete list l...@domain.org delete domain domain.org What I belive is that deleting a domain should not strightforward, any destructive command should not be. Would it not be nice to prompt the user once before deleting? as in There are 100 lists associated with this domain. Once deleted you cannot undo it, Do you really want to delete x...@yyy.com?[y/n] Or maybe it could schedule a deletion after a pre-defined time with a reasonable default lets say 1 Day? And for an urgency(to delete) there could be --force argument? 2. Begin the third `scope` user and add methods like create, delete and list. create user f...@bar.com --password PASS --name NAME list user [--verbose] [--no-header] The user class would be built and managed in the same way as other classes. r55 would be an easy one. Once the above changes are approved, r55 can be completed in a day. I roughly went through your code, and I have a few more points: * You should write tests, before writing more code. Infact you should follow TDD (ofcourse if you are comfortable doing it) since the outcome of your commands is less likely to change, even though your code does. * The commit messages should be written in a language that tells a reader What this commit does?. Like Adds documentation file using.txt. Instad of answering What I have done in this commit? Although it is my point of view, AFAIK it is also preferred by many other developers.(See commit messages of barry on lp:mailman) ___ 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/raj.abhilash1%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 -- thanks, Abhilash Raj ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 lists Right? Since this tool is meant for the users, you should write better documentation. Like in using.txt#39 what does long listing mean? What does `--verbose` do for listing a domain? Or even for listing all the lists? As I understand using.txt is more of a command reference than documentation? Are there only these two options for lists and domains? What about editing any list? Adding and removing user roles will be possible after you have create the `user` scope but editing of other parameters can be done? No, there are more options for lists and domains, many of which are dependent on the users. Some of the other options are list-members, edit and export(to CSV)/import. Hence, these would be easier to build after a basic user class is available. 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 you want to create one? [y/n] Just adding all the options using argparse is really not a very tough job (and with your pace, it is definitely not going to last more than one month ;-). Try to put some more thought to how you can make this tool more intuitive for the end user. What I belive is that deleting a domain should not strightforward, any destructive command should not be. Would it not be nice to prompt the user once before deleting? as in There are 100 lists associated with this domain. Once deleted you cannot undo it, Do you really want to delete x...@yyy.com?[y/n] Or maybe it could schedule a deletion after a pre-defined time with a reasonable default lets say 1 Day? And for an urgency(to delete) there could be --force argument? I roughly went through your code, and I have a few more points: * You should write tests, before writing more code. Infact you should follow TDD (ofcourse if you are comfortable doing it) since the outcome of your commands is less likely to change, even though your code does. * The commit messages should be written in a language that tells a reader What this commit does?. Like Adds documentation file using.txt. Instad of answering What I have done in this commit? Although it is my point of view, AFAIK it is also preferred by many other developers.(See commit messages of barry on lp:mailman) Everything else seems fine. Will apply the necessary changes. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 else use optional args E.g, To filter mailing lists based on domains, do mmclient show list --domain domain.org and not mmclient show list domain.org To create a list, do mmclient create list l...@domain.org instead of mmclient create list --list list --domain domain.org 2. Added a no-header option to the detailed listing so that it becomes easier to pip the output. I will be making the following changes for r55 1.Delete Quite a straightforward one. delete list l...@domain.org delete domain domain.org 2. Begin the third `scope` user and add methods like create, delete and list. create user f...@bar.com --password PASS --name NAME list user [--verbose] [--no-header] The user class would be built and managed in the same way as other classes. r55 would be an easy one. Once the above changes are approved, r55 can be completed in a day. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 action *list* with *show* The change mentioned in point 2 solves many/most of the problems raised during the recent discussions. The options are now paired with their corresponding sub commands. The implications of this change is that the extra options/arguments raise command syntax errors, which were ignored earlier. Further, an great extent of leniency can be allowed in the command format. To be specific, the parser can support the commands *mmclient create list --list list1 --domain domain.org* and *mmclient set --key foo --value bar* at the same time. Note that the second command has not specified a scope.(PS: scope as in list, domain, user etc, and not site-wide, domain etc). The change also prevents argparse from generating a dictionary with all possible options (which may be huge). The agreed change to add a positional argument for the *name* (commands of the form *mmclient create list l...@domain.org*) has been postponed to the next revision, as this revision mostly contains code refactoring. http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/53 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 ? In the command *mmclient scope action* , the scope denotes the class name and the action denotes the class method to be invoked. The following format suggested by you, mmclient show --listname=l...@example.com --domain=example.org From the developer point of view, its difficult to map an action to a class by using this format. For eg, the above command can be associated with the class domain or list, as the order of the arguments is insignificant. Further, the commands do not offer much advantage to the user in terms of usability. Most of the current (frequent) commands are quite straightforward and similar to the ones to be used in the shell, for eg, *create list l...@domain.org* compared to *create --listname=l...@domain.org*. Some commands like *add-role* are less intuitive in this format,yet provide a tolerable level of understandability. which makes the outcome dependent on the order in which the if-else's are written. This is a serious bug when actions like `delete` are being used. Destructive actions should probably be more constrained in what they allow, so that there's no possibility of ambiguity on either the part of the user or the code. In the face of ambiguity, refuse the temptation to guess. Got a bit confused with the use of *scope* in this context. Anyways, if the scope is not specified, apply the setting on a default *scope*, `default=site-wide` makes sense, while others do not. Hmm. If scope is optional (because it has a default), then it's not a required positional argument, right? So shouldn't a --switch should be used? A switch would work best when the number of possible choices are very few. Here we have the following choices for the scope, site-wide, domain and list. It seems OK to use a switch here. However, using switches limits the extendibility of the scopes. If a new scope is to be added some day (something server-wide?), integrating new switches is not an easy task, when compared to the addition of a new choice for scope in current approach. And as the final word, I am ready to change the command style, mmclient action scope arguments if there is some serious disagreement with it. 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 translatable between the two. The current format of commands,mmclient scope action arguments is directly translatable to the shell. In fact, they are almost similar, except for the `--` in the commands. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 the command line, because argparse makes a strong distinction (and corresponding associations) between *required positional* arguments and *optional* keyword-like arguments (ie, any argument with leading dashes). Positional arguments *can be made* optional, also be supplied with a default value, in case the argument was not specified. In my opinion, I don't like the `one level of sub command` as neither the user nor the developer is benefited of such a design. The user ends up typing the same strings as before plus an extra `--` followed by the same set of arguments. And from the angle of implementation, each of the *scope* name would require a different optional argument, followed by a set of if-else's to land at the right *scope* to manage. Further there is a possibility of the user specifying multiple scopes, mmclient show --list --listname l...@domain.org --domain which makes the outcome dependent on the order in which the if-else's are written. This is a serious bug when actions like `delete` are being used. 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. mmclient set --key name --value value This seems unnecessarily verbose on the one hand, and to not actually correspond to an actual use case, on the other: there's no scope mentioned. I feel the scope should be mandatory, even if it's sitewide: mmclient set --site-wide --key CAN_PERSONALIZE --value No mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes (after the first one, the second would be an error, I guess, but in other cases a site-wide setting would be interpreted as a default). Got a bit confused with the use of *scope* in this context. Anyways, if the scope is not specified, apply the setting on a default *scope*, `default=site-wide` makes sense, while others do not. I guess this horse has already bolted the barn, but I wonder about a syntax like mmclient set --site-wide --key PERSONALIZE --value Permitted mmclient set --domain=python.org --key PERSONALIZE --value Permitted mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No for resource constraining settings. (Permitted could probably be an alias for False.) 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. 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. And as the final word, I am ready to change the command style, mmclient action scope arguments if there is some serious disagreement with it. Steve ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 replacement for that. Thanks. 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.) ... Yuck. Sorry but I'd like to discourage the use of made up or concatenated words. It's okay for some options to be multi-word separated by dashes, e.g. --affect-bar or --change-foo. I don't have a good alternative atm. Will do. E.g. mmclient set --key name --value value I have answered this part and the `one level subcommand` part in the reply to Steve's mail. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 normal to me. mmclient set --key name --value value This seems unnecessarily verbose on the one hand, and to not actually correspond to an actual use case, on the other: there's no scope mentioned. I feel the scope should be mandatory, even if it's sitewide: mmclient set --site-wide --key CAN_PERSONALIZE --value No mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes This seems different than what Rajeev wrote, where he mentions that the 'setting' argument is the scope: On May 11, 2014, at 10:37 PM, Rajeev S wrote: *Preferences/settings* Settings would form a new `scope`, commands for which can be implemented in a fairly straightforward way. mmclient set setting setting name --value value On May 13, 2014, at 01:45 AM, Stephen J. Turnbull wrote: (after the first one, the second would be an error, I guess, but in other cases a site-wide setting would be interpreted as a default). I guess this horse has already bolted the barn, but I wonder about a syntax like mmclient set --site-wide --key PERSONALIZE --value Permitted mmclient set --domain=python.org --key PERSONALIZE --value Permitted mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No I think that would be fine (probably --site is sufficient, and a bit shorter). Also I would suggest allowing either List-ID or posting address as an argument to --list, e.g. --list=mailman-users.python.org would also be acceptable. Usually there will be no difference, but lists can be renamed and the List-ID will never change. Cheers, -Barry signature.asc Description: PGP signature ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 shorter: mmclient show --listname=l...@example.com --domain=example.org ? which makes the outcome dependent on the order in which the if-else's are written. This is a serious bug when actions like `delete` are being used. Destructive actions should probably be more constrained in what they allow, so that there's no possibility of ambiguity on either the part of the user or the code. In the face of ambiguity, refuse the temptation to guess. Got a bit confused with the use of *scope* in this context. Anyways, if the scope is not specified, apply the setting on a default *scope*, `default=site-wide` makes sense, while others do not. Hmm. If scope is optional (because it has a default), then it's not a required positional argument, right? So shouldn't a --switch should be used? 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. 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. And as the final word, I am ready to change the command style, mmclient action scope arguments if there is some serious disagreement with it. 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 translatable between the two. -Barry signature.asc Description: PGP signature ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 l...@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-l...@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 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 list. In such cases, options like `domainname`, `listname` and `username` would be more intuitive than using options like `in-domain`. You'll want to take a cue from the `mailman create` command, and as a general rule, I think the shell-cli should be as similar as possible to the rest-cli. I'm open to modifying the former in order to better align them, as long as we have a consistent view of commands and options across both tools. Let's not go down the accretion-without-design path of git. :) -Barry ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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] mmclient list user [l...@domain.org] [-v for verbose] [--role ROLE] mmclient list domain [domain.org] [-v for verbose] 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. 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.) *Role management* User roles can be managed by two actions, addrole and removerole, rather than 6 separate actions for subscribe, unsubscribe, addowner, addmoderator, removeowner, removemoderator Yuck. Sorry but I'd like to discourage the use of made up or concatenated words. It's okay for some options to be multi-word separated by dashes, e.g. --affect-bar or --change-foo. I don't have a good alternative atm. *Preferences/settings* Settings would form a new `scope`, commands for which can be implemented in a fairly straightforward way. mmclient set setting setting name --value value E.g. mmclient set --key name --value value -Barry ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 (and corresponding associations) between *required positional* arguments and *optional* keyword-like arguments (ie, any argument with leading dashes). In the model Rajeev has shown so far, the scope argument (list, domain, user) hasn't been optional. mmclient set --key name --value value This seems unnecessarily verbose on the one hand, and to not actually correspond to an actual use case, on the other: there's no scope mentioned. I feel the scope should be mandatory, even if it's sitewide: mmclient set --site-wide --key CAN_PERSONALIZE --value No mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes (after the first one, the second would be an error, I guess, but in other cases a site-wide setting would be interpreted as a default). I guess this horse has already bolted the barn, but I wonder about a syntax like mmclient set --site-wide --key PERSONALIZE --value Permitted mmclient set --domain=python.org --key PERSONALIZE --value Permitted mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No for resource constraining settings. (Permitted could probably be an alias for False.) Steve ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Fri, May 2, 2014 at 9:06 PM, Rajeev S rajeevs1...@gmail.com wrote: 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 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 are also not added.(Is it still necessary?) Files should definitely all have licensing blocks. ^Ls are not required. I find them useful for Emacs navigation, but I understand they may be distracting for other folks in other editors. I really need to update the style guide for Python 3 and not-quite-Python-3-yet. -Barry ___ 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/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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: read-only (news) read-post (moderated or not) Excuse my imprecise terminology. Best regards, -Tom ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 $DAYJOB stuff that will prevent me from reviewing until at least Monday evening (Japan time), but thank you for posting and keeping all of us updated. ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 effect do you want it to have? ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 (moderated or not)
Not in that terminology, no. What do you hope to type, and what
effect do you want it to have?
We had a little discussion last year about list styles. See this thread:
http://www.mail-archive.com/mailman-developers%40python.org/msg13369.html
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.
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 code):
test_one = example.create_list('test-one', style='read-only')
Looking briefly at the cli code I see nothing about the list
attributes Barry mentioned in last year's thread referenced above, so
I'm not sure how this would all fit together, but I think it needs to
be considered.
I hope this makes some sense from a very interested user.
Best regards,
-Tom
___
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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 providing some kind of scriptable interface (even a simple way to store a sequence of commands acting on the current list should suffice, where current list is a concept his proposal already includes) would allow it to be implemented relatively easily. I'll discuss that with Rajeev later. Still, I would expect that the right place to expose a list style capability is in Postorius. Most list admins are not even going to have access to the CLI, most likely, because we have *no* security model for it yet, except shell access to the list host. The CLI is going to be a power user's and sysadmin feature more than the way to manage lists for most people, AIUI. (Again, this is negotiable with the student.) Also, list styles probably should be stored in the Mailman core so they can be accessed from any client (which is what takes it right out of the scope of this GSoC IMO, although that's negotiable, again according to Rajeev's interest). HTH, Steve ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 code):
test_one = example.create_list('test-one', style='read-only')
Looking briefly at the cli code I see nothing about the list
attributes Barry mentioned in last year's thread referenced above, so
I'm not sure how this would all fit together, but I think it needs to
be considered.
Using MM3's internal API:
from mailman.app.lifecycle import create_list
mylist = create_list('t...@example.com', style='legacy-announce')
Using the REST API
http://pythonhosted.org//mailman/src/mailman/rest/docs/lists.html#apply-a-style-at-list-creation-time
The CLI (i.e. `mailman create` command) does not yet accept a --style
argument, but that would be pretty trivial to add.
Note that currently only the legacy-default and legacy-announce styles are
defined by default.
Cheers,
-Barry
___
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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 create` command) does not yet accept a --style
argument, but that would be pretty trivial to add.
Note that currently only the legacy-default and legacy-announce styles are
defined by default.
Great, the 'legacy-announce' style sounds like a 'read-only'/'news'
list! I hope so because that's just what I'm looking for.
Best,
-Tom
___
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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 current list is a concept his proposal already includes) would allow it to be implemented relatively easily. I'll discuss that with Rajeev later. Still, I would expect that the right place to expose a list style capability is in Postorius. Most list admins are not even going to have access to the CLI, most likely, because we have *no* security model for it yet, except shell access to the list host. The CLI is going to be a power user's and sysadmin feature more than the way to manage lists for most people, AIUI. (Again, this is negotiable with the student.) Adding a list style attribute would be simple to implement, as Barry had mentioned. Also, list styles probably should be stored in the Mailman core so they can be accessed from any client (which is what takes it right out of the scope of this GSoC IMO, although that's negotiable, again according to Rajeev's interest). I have not concentrated much on the mailman core as it has least to do with my proposal. All I have done with the mailman core is to go through the table schema as it might be useful for the command shell. However, I will give it a try. HTH, Steve ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 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 are also not added.(Is it still necessary?) Files should definitely all have licensing blocks. ^Ls are not required. I find them useful for Emacs navigation, but I understand they may be distracting for other folks in other editors. I really need to update the style guide for Python 3 and not-quite-Python-3-yet. -Barry ___ 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/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ 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
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
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 are also not added.(Is it still necessary?) Files should definitely all have licensing blocks. ^Ls are not required. I find them useful for Emacs navigation, but I understand they may be distracting for other folks in other editors. I really need to update the style guide for Python 3 and not-quite-Python-3-yet. -Barry ___ 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
