[Mailman-Developers] MM command prefix and-or single mm-admin CLI frontend

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 7, 2008, at 5:25 AM, Andy Buckley wrote:

> It sounds trivial, but one thing that I've always regarded as a
> usability problem in MM2 is the proliferation of admin command  
> names. As
> a terminal junky, a common way to learn the functionality of a
> multi-purpose set of command line tools is to type their common prefix
> and press tab to see what commands are available. In MM, there is no
> common prefix, so this option isn't available and memory is needed to
> remember the right command name... commands like 'newlist' and
> 'config_list' are spread higgledy-piggledy through name-space rather
> than being neatly stacked in one corner. It would be great for  
> usability
> if MM3 could use admin commands with e.g. a "mm-" prefix (with
> installation of backwards compatible versions maybe as an option)

Andy, I feel exactly the same way!  As Stephen points out, the  
tradition in Mailman has been to separate Mailman's command name space  
into its own 'bin' directory, which at least helps reduce the command  
line pollution.

> An alternative approach, used most prominently by Trac, is to have a
> single admin command which can either behave like a non-interactive
> process or a subcommand interpreter, depending on how it is called. I
> would be happy to spend some time on a mm-admin command, using the  
> same
> Python "cmd" module as trac-admin if there is the interest. This might
> also involve moving some of the intelligence out of the admin scripts
> and into the API, which is also good news for people like me who  
> have a
> need/desire to hook MM into a wider system management framework.

Mailman 3 definitely takes this approach, aided in large part by  
setuptools.  Ideally, there should be little but option parsing shim  
in the command modules, but even there, with setuptools, we're able to  
move everything into the mailman.bin package so at least it's / 
feasible/ to import it and use it.  The code in the mailman.bin  
modules are not always organized in a convenient way though.  I have a  
strong desire to change that (there should be no unique logic in a  
mailman.bin module).

I like the idea of a master command, and quite naturally I would  
choose 'mailman'.  I didn't know that Trac did this, but lots of other  
programs do, and I would look at the Bazaar code to see if there's  
anything we can steal there too.  If there's a Cheeseshop package we  
can just use, all the better.

Now that Python 2.6 is out, and 3.0 nearly so, I'm hoping to shift  
most of my free hacking time back to Mailman 3.  All help with the  
command reorganization would be welcome.

Another thing to think about is bringing sanity to the command line  
options.  Those are about as inconsistent as you can get too, though  
MM3 tries to bring some sanity back there.  For example, some commands  
take a -l option to specify the list name they operate on, others use  
a required positional argument.  Blech.

> PS. I'm also interested in taking a look at MM3 templating... is this
> being actively worked on or did it stall after the GSoC effort?

It's not being actively worked on, but I'd like it to be.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkkV1uAACgkQ2YZpQepbvXE19wCfVgqBWpah2Yeft9SDk9vs0qoe
p2MAnA6udvrP8mm6eak6TjZOI9Ui5Jf8
=2HOW
-----END PGP SIGNATURE-----