[ditz-talk] Some work on ditz
wmorgan-ditz at masanjin.net
Wed Jul 30 16:09:54 EDT 2008
Reformatted excerpts from Ohad Lutzky's message of 2008-07-29:
> However, now I realize trollop is also yours, so it makes more sense
> to hack on that...
Yes, I'm generally happy to develop trollop, using ditz as a use case.
> For now I've hacked around the issue I was having (trollop was
> "stealing" flags from the subcommand, and stop_on couldn't be
> specified without the hack in
> 126f410e7ebc900f2b60abf124cda042a4e07a6c. So I figured we might want
> to bring that hack straight into trollop - add a general
> "stop_on_subcommand" flag which doesn't need to know what the
> subcommand would be.
Adding an unconditional "stop at first non-option argument" to Trollop
is a good idea.
But I also think we should just remove the :plugins_file option from
ditz. I added it on a whim, and I don't think it's useful, and since
plugins can affect parsing, you can construct ambiguous/paradoxical
commandlines like "ditz --plugin-file a b --plugin-file c". If a is a
plugin file that doesn't add b as a command, then should ditz unload it
and load c instead? What if c is a plugin file that does add b as a
command? Should ditz simply explode in a ball of fire?
Does anyone make use of the --plugins-file option? I could make it an
environment variable instead.
William <wmorgan-ditz at masanjin.net>
More information about the ditz-talk