Open Stack

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