[ditz-talk] Operator Arguments
wmorgan-ditz at masanjin.net
Tue Jun 17 12:50:20 EDT 2008
Reformatted excerpts from Daniel Hackney's message of 2008-06-16:
> Since there is the "short circuit" functionality of the `--commands'
> argument, it may make sense to have a small file with the information
> about the commands and then all of the code separate. Then again,
> since the amount of time it takes to parse some extra classes is
> probably pretty minimal, worrying too much about this is probably a
> waste of effort.
I also think it would be wasted effort. The --commands case is special
and it makes sense to make that as fast as reasonably possible.
Everything else should stay as it is.
> I think what I'll do is finish writing it with CmdParse/OptParse,
> present it to you, and if you think that it is still to clumsy, I can
> look at adding operator arguments to Trollop and then converting my
> patch to use that.
It's fine if you want to continue down that route, but I will tell you
now that I not accept patches that replace Trollop.
The good news is that I've just released a new version of Trollop (1.8)
which has a "stop_on" method that halts option parsing when the given
tokens are encountered. If you want to try and plug that into ditz,
here's the interface I'd like to see:
1. Have the "operation" method take an optional block where you can
specify per-operation arguments, like so:
operation :todo, "Generate todo list", :magic_release do
opt :all, "Show all items, not just incomplete ones"
2. Make it so that the config hash that's passed in to operation
methods has both the config file options and the command-specific
options mashed into the same namespace. (At some point I'm going to
mash $opts into there too so there are no more global variables.) If
there's a namespace conflict, options should trump config file.
3. For operations that don't have any options, nothing should have to
This is something I've been thinking about for a while. You're welcome
to take a stab at it. Probably best would be one patch that adds that
functionality, and then a patch per operation to add arguments and their
> From what I could tell, all you really need to do is to pass enough
> stuff in the ":with" hash option to keep it from asking anything. It
> might be nice to have some list of the options each operator needs in
> order to run in batch mode and fail if they are not met.
The list of requirements will have to be generated from the model
objects, since they're the ones that have that information. (And in the
future the set of fields will be modifiable by the user.) It probably
makes sense to have a Model.create_noninteractively that dies with
incomplete information rather than prompting. Haven't really thought it
This should definitely be a separate patch, though.
William <wmorgan-ditz at masanjin.net>
More information about the ditz-talk