Half Way through the GSoC

Half of the GSoC is done and I am happy that I have been able to cope up with the deadlines I have set in my proposal. The Mailman CLI is almost fully done and can be used comfortably to manage a mailman installation.

At the end of the first phase of the project, the CLI supports 11 commands in 4 scopes, resulting in almost 25 actions that can be performed on Mailman.

Here is a snapshot of the functionalities that can now be performed using the CLI

It was suggested to me to follow TDD, and I liked the approach too. But when most of the newer commands printed an output rather than performing action, TDD became painful, consumed too much of my time and proved to be awfully boring. I spent days writing test code rather than the functionalities of the CLI. Finally, I dropped the test writing and continued with the projects. I will be writing tests as proposed in my proposal, during the week of mid term evaluation and during last week of the project.

As part of the TDD process, A lot of code refactoring was done to make the code compatible with the unittests. The most important decision was about how the errors were handled. Until then, error messages were printed directly to stdout. There were no means of using these modules in an external project, as the errors could not be caught. The unittest module's assertRaises method seemed to be the easiest way to test many of the functionalities. Hence I replaced all the `print errors` with a raise expression. Along with this, custom exception classes were built for each scope. All these custom error messages were caught at a single point and printed to stderr (just changed it from stdout to stderr, change to be applied from r61).

All other messages, which are not part of the output of commands, like errors and confirmation messages, are printed in cute shades like red for error, yellow for warning and green for confirmation and emphasized messages. These help the messages to standout in a terminal. The colors were added very easily using the corresponding escape codes for each color. This functionality is encapsulated in a class named Colorize, which contains methods like warn, error, emphasize and confirm.

The project now enables the users to manage a mailman installation with ease, allowing them to make changes with a single command. Most of these actions previously required the user to write scripts on the python shell. Now most of the common actions on Mailman is a single command away.

Other interesting stuff used in the project include the tabulate module, which handles the headache of output formatting, especially when the output is huge, as is the case of many commands in the CLI. I had used the difflib.get_close_matches function to suggest the possible keys for preferences, but removed it on finding a better alternative. The nosetests + unittest suite manages all my test cases and test execution process. This was my first encounter with the unittest module and unittest'ing.

The argparse module takes care of all my command linHalf of the GsoC is done and I am happy that I have been able to cope up with the deadlines I have set in my proposal. The Mailman CLI is almost fully done and can be used comfortably to manage a mailman installation.e arguments , usage help for commands and proper error reporting. I had used optparse before, but not in this scale. Last but not least, the bzr+launchpad duo, which again is new to me, but a lot similar to git. However, bzr lacks many of the handy features that git has, like git grep and the log is inverted by default.

The next phase of project is even more interesting, which involves building a custom shell, which, in effect involves building a query language. I guess I will make use of the recurrence descent parser for that purpose. From the looks of it, the commands would be almost similar in both, the CLI and the shell. I will have to come up with a fair design for the parser the coming week, in addition to writing tests for the work until now.