[Yum-devel] Making plugins more reliable for non-cli users

Tim Lauridsen tim.lauridsen at googlemail.com
Fri Dec 28 07:51:14 UTC 2007


Jeremy Katz wrote:
> There seems to be a bit of a theme of plugins classifying themselves as
> non-interactive (TYPE_CORE) but still depending on some of the pieces
> presented by the cli, especially with regards to option parsing.  This
> leads to pretty regular tracebacks for pirut and other non-cli users :(
> 
> The question is what can we do to make plugins more reliable for other
> API users.  Do we
> a) just punt on the use of plugins from non-cli users[1] and disable
> plugins there
-1, plugins can be very useful for non-cli users, i don't think this is 
an option in RHEL, the rhn plugin is needed to get updates etc.
> b) suck it up and add at least a dummy command line for other API users
> so that plugins can expect to always be able to access it[2]
In yumex i create parse on the command line to plugin, so i can use 
somethine like 'yumex --skipbroken' to activate plugins the need command 
line options.

> c) add some form of checking and raise errors if plugins do things with
> the command line but are of type TYPE_CORE.  This would at least make it
> so that they would also traceback for cli users and thus hopefully avoid
> some of the problems
> d) something else?

Catch traceback in the plugin hooks and convert them to some kind of
TrackbackInPlugin Exception to make it easier to catch and tell the user 
there is some kind of problem in plugin 'xxxxx'. it can be useful in 
both cli and noncli.

building a common noncli/gui api for yum gui could also be a way to go, 
it could make it easier to control how the base API is used from a gui, 
and make the diffent gui tools act more in the same way.

Tim



More information about the Yum-devel mailing list