Open Stack

Excerpts from Doug Hellmann's message of 2018-01-18 10:15:16 -0500:
> We've been working this week to resolve an issue between cliff and
> barbicanclient due to a collision in the option namespace [0].
> Barbicanclient was using the -s option, and then cliff's lister
> command base class added that option as an alias for sort-columns.
> 
> The first attempt at resolving the conflict was to set the conflict
> handler in argparse to 'resolve' [1]. Several reviewers pointed out
> that this would have the unwanted side-effect of making some OSC
> commands support the -s as an alias for --sort-columns while the
> barbicanclient commands would use it for a different purpose.
> 
> For now we have removed the -s alias from within cliff. However,
> we want to avoid this problem coming up in the future so we want a
> better solution.
> 
> The OSC project has a policy that its command plugins do not use
> short options (single letter). There are relatively few of them,
> and it's easy to introduce collisions.  Therefore, they are seen
> as reserved for more common "global" options such as provided by
> the base classes in OSC and cliff.
> 
> I propose that for Rocky we update cliff to change the way options
> are registered so that conflicting options added by command subclasses
> are ignored. This would effectively let cliff "own" the short option
> namespace, and require command classes to use long option names.
> 
> The implementation details need to be worked out a bit, but I think
> we can do that by subclassing ArgumentParser and adding a new
> conflict handler method similar to the existing _handle_conflict_error()
> and _handle_conflict_resolve().
> 
> This is going to introduce backwards-incompatible changes in the
> commands derived from cliff, so before we take any action I wanted
> to solicit input in the plan.
> 
> Please let me know what you think,
> Doug
> 
> [0] https://bugs.launchpad.net/python-barbicanclient/+bug/1743578
> [1] https://docs.python.org/3.5/library/argparse.html#conflict-handler

I have a patch up to implement this in https://review.openstack.org/538335

Doug