[RFC] Optparse option handling

Robert Collins robertc at robertcollins.net
Wed Aug 16 03:28:21 BST 2006


On Tue, 2006-08-15 at 09:17 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > On Fri, 2006-08-11 at 09:06 -0400, Aaron Bentley wrote:
> > 
> >>>I actually kind of like 'bzr foo --option=baz' for enumeration
> >>
> >>options,
> >>
> >>>but I may be unique in this. 
> >>
> >>It wouldn't be hard to retain --branch-format=foo, (not --format=foo)
> >>if
> >>that's desirable.
> > 
> > 
> > Curiosity here - why cant we do --format=foo anymore ? [I've been in
> > optparse' guts, I dont think theres any fundamental restriction on this]
> 
> There were two reasons I didn't want to:
> 1. repository formats are different from branch formats and working tree
> formats.  I would prefer for all our options to be distinct.  This also
> allows them to be globally-registered, and referred to with
> takes_options=['branch-format'].

Ah. Well in the code there is only one format that is passed to apis
like clone/sprout/upgrade - a control dir format. For BzrDirFormat this
is a composite object that can optionally specify working
tree/branch/repository formats by having the right attributes set. So
'metaweave' means 'BzrDirMetaFormat1() + MetaWeaveRepositoryFormat()'. I
don tthink there is any benefit by making the 4 formats separate, as
they are not combinable in arbitrary forms - its simpler to just
explicitly name the combinations we want to support people requesting. 

> 2. I'm deriving the option name from the string that is used in the help:
> 
> ...
>   Branch Format:
>     --default    The current best format (knit)
> ...
> 
> So "Branch Format" is transformed to "branch-format".  This allows
> EnumOptions to be more succinct, which was a big concern of mine-- I
> wanted EnumOptions to be a clear win over just invoking parser.add_option.
> 
> So no, it has nothing to do with the technical capabilities of optparse.

Hmm. I personally dislike magic interfaces that derive parameters like
that. Can we make it explicit please?

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060816/254c47cc/attachment.pgp 


More information about the bazaar mailing list