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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev