MM command prefix and-or single mm-admin CLI frontend
Hi,
I've been meaning to send this mail for a long time, but for one reason or another (mostly fear of making UI suggestions for a project whose internals I don't really know) have repeatedly managed to put it off!
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)
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.
Anyway, that's the idea --- what do you think? And apologies for being presumptuous ;)
Best wishes, Andy
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?
Andy Buckley writes:
In MM, there is no common prefix
Since most commands work best from the Mailman home directory, "bin/" works fine for me.<wink>
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 say that the big advantage is not so much the "prefix" aspect, but rather the ability to give helpful help, such as brief descriptions or required arguments, and also to have a "mm help <cmd>" version for details on each command.
-----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-----
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.
This interface style seems to be gaining popularity, so even if it's not the only interface it's probably a good supplement. I think I first noticed it with openssl, and immediately took a liking to it.
Mercurial is another example of a Python program with a thin subcommand driver program. It might be more or less suitable for theft as well. (N.B. Mercurial is GPL v2, not v3.) Mercurial's driver calls commands as python functions from the mercurial library, and provides a nice extension framework for enabling users or third parties to extend the base functionality with additional python modules. Not sure whether bzr or trac-admin has something similar, but it may be another reason to look at how hg does it.
-- -D. dgc@uchicago.edu NSIT University of Chicago
participants (4)
-
Andy Buckley -
Barry Warsaw -
David Champion -
Stephen J. Turnbull