any optparse branches floating around

[John Arbash Meinel]

Aaron Bentley wrote:
> Martin Pool wrote:
> | We just had #46432, where bzrtools accidentally overrides the
> | description of another command's option.  I would like sometime to clean
> | up the option code to make it less dependent on global definitions, e.g.
> | in defining short names.
> 
> I don't think we'll see much more of that-- that part of bzrtools was
> written when adding to OPTIONS was the only way to define new options.

Well, it was also for stuff like allowing '--long, --short, --line' to
all set the same variable, rather than setting separate variables.
And also to allow '-r 10 -r 20'.

We've pretty much kept the 'consistency' rule that short options always
expand to the same long option. Which is very nice from a consistency
standpoint, but does mean that there are places where we might like to
have a short option, but can't.

> 
> | Before I do - does anyone have a patch/branch to use optparse instead of
> | handcoded parsing?  There seemed to be a consensus this would be a good
> | thing to do?
> 
> Not I.
> 
> Aaron

I thought there were some other people who were interested in it, but
haven't heard from them in a long time.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060525/f489f93e/attachment.pgp