Since I started writing Bazaar plugins though, I've fallen in love with Bazaar's command interface. Jamu has too, so he wrote Commandant. I don't really understand it though, which is mostly for lack of trying.
Michael turned our internal EC2-using testing tool into a bzr-a-like app using the Bazaar APIs. There's a bit of duplication, but it works pretty well.
The Bazaar developers are aware that their command-line interface code rocks and that it's too closely bound to Bazaar. I'm not sure whether anyone has filed bugs about it or not, but here's what I actually want:
- The subcommand interface, e.g. "bzr foo"
- Option parsing
- Help
- Command aliasing
- Error handling
- Progress display
- Verbosity control
- Logging
- Debug helpers (e.g. The way bzr handles Ctrl-\)
There's also a bunch of cool stuff in Bazaar that's useful for a lot of applications, command-line or not.
- Registries
- Transports
- Hooks
- Configuration files
- Oh yeah, plugins. (How could I have forgotten this?)
Sometimes I wish projects like Bazaar and Twisted split this sort of stuff out into separate packages. That would probably change the way the packages are maintained, and I don't know whether it would be for better or for worse.
Sadly, no moral or action for this post. Just stuff that's been on my mind that I wanted to write down and publish. I'd very much welcome input.
Update: Was rewriting this post, then realized that, umm, well, it was a rewrite.
Update: Was rewriting this post, then realized that, umm, well, it was a rewrite.
5 comments:
This seems like the kind of thing a bounty would be good for, actually.
I'm generally pretty sceptical of bounties: "here's $200 to do $3000 worth of software development, oh, and we'll haggle over standards just as much as we would if we were paying $3000." But this sort of task strikes me as fairly well defined, unlikely to blow out significantly in estimates, a bit low priority and unexciting for core volunteers, potentially high impact in terms of users.
I want to add support to Commandant for command aliasing (which implies some kind of configuration file handling), progress display and plugins. I'm not sure what you mean by 'error handling', but at present Commandant displays str(exception) when an exception is raised by a command.
If you have any advice on how to make it easier to figure out what Commandant is for, I'd love to hear it. Also, thanks for publicizing Commandant!
Dammit. I wrote a reply which then got lost.
Here it is again, from memory.
Jamu, as I said, I've only ever had a fairly shallow look at Commandant. Here are a few things from skimming the README:
* I don't want to have to use shell aliases to have my program be called by its proper name.
* I dislike the idea of putting files in a directory to get commands. I'd much rather an explicit registry.
* I don't want the word "Commandant" appearing in the output of my program.
Maybe what all of this means is that I was looking for a library, and the README makes it look more like a framework. This is all rather shallow, of course, since I still haven't actually tried to use it in anger.
Hope this helps.
jml
Most of the features you list are available with the popular argparse library.
As for “progress bar”, I don't think that belongs much in a command-line parser library; a separate facility for progress bar output seems more suitable.
Thanks bignose, I hadn't heard of that one. I'll take a look at it.
I agree that a progress bar is separate from a command-line parser, but it's not separate from a command-line app toolkit. I could have made my point better, but what I meant is that Bazaar has a great command-line app toolkit begging to be separated from the dvcs bits.
Post a Comment