[RFC] use optparse for option handling

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Here's a bundle that uses optparse as a backend.
> 
> This gets us out of the option-parsing business, and it also clears the
> way for using advanced optparse features.

Nice. We've wanted to do this for a while. I wonder if it is appropriate
for 0.9 with the release being this close... (remember the
file_ids_involved_by fiasco)

> 
> We need enumerations-- that is, flags that set the same variable to
> different values.  Log formats and merge types should be handled that
> way.  It might also be nice to have -v increase the verbosity level.
> 
> I really like our frontend-- I find it much nicer to use than doing
> optparse directly.  (Bugs Everywhere does that, and it's a PITA.  I
> guess optparse is fine if you don't have lots of subcommands.)
> 
> There is one behaviour change: it's now legal to specify the same option
> multiple times (the last value is used).

I think we want this, though. Mostly, it helps with aliases, since you
can override the default.

Also, optparse supports 'list' style arguments, that keep tacking on new
values. Which might be nice to let us support '-r 1 -r 2'. Though I
prefer '-r1..2' syntax myself.

> 
> Optparse wants to determine the 'final value' of options by filling in
> defaults, but we want to let command defaults determine that, so we use
> a unique default value, and filter out options assigned to that value.
> 
> (btw, is there a way to prevent that string from being interned?  I
> don't want false negatives from
> "if v is not OptionParser.DEFAULT_VALUE")

There are a couple possibilities.

1) Use a list, I don't think they are ever interned.
  DEFAULT_VALUE = []
or
  DEFAULT_VALUE = ['my_custom_list']

2) Create the string from bits
  DEFAULT_VALUE = 'default' + ' string'

3) Use a space, it doesn't look like a valid variable name, so python
doesn't default to interning it
  DEFAULT_VALUE = 'default string'


> 
> There are no new tests, though the existing blackbox tests provide
> pretty good coverage.
> 
> Aaron

Might be good to have some direct tests on the option parser. The code
itself looks pretty good. But especially without tests I would be more
content to add it after 0.9 releases, so we have some bzr.dev time to
ferret out any bugs/complications.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtUiHJdeBCYSNAAMRAlNQAKCg3c8J6467LioH6BxhMLZyNr0apgCePlpy
/RkFOchZ5TA2mQyE7FyXQqA=
=Y158
-----END PGP SIGNATURE-----