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

Tim Lauridsen tim.lauridsen at googlemail.com
Fri Dec 28 15:44:13 UTC 2007


Jeremy Katz wrote:
> On Fri, 2007-12-28 at 08:51 +0100, Tim Lauridsen wrote:
>> 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.
> 
> That's why I said that really this would be making an allowed list of
> plugins.
> 
>>> 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.
> 
> Depending on a command line to exist and be usable is a non-starter.  If
> your plugin requires a command line options, it's not TYPE_CORE.
> Remember -- this isn't just things like yumex or pirut.  It's also
> anaconda, livecd-creator, pungi, and more.  It just hits the latter set
> less because the anaconda environment is pretty controlled and
> livecd-creator and pungi are run by a lot fewer people.
> 
>>> 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 ande 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.
> 
> This would still mean that basically the entire app would have to run
> under try/except PluginError.  And that still just ends up meaning that
> the user gets relatively screwed.
> 
In the PackageKit yum backend i have created a custom exception handler 
to catch all unhandled tracebacks and send all traceback info to the 
packagekit frontend in a predefined error format.
http://gitweb.freedesktop.org/?p=packagekit.git;a=blob;h=170d9cc416ab8353f94d7f41912a624016cf7f90;hb=95f7d17acf8d2194d6edd312934a602e63cf4d21;f=python/packagekit/backend.py

in this way it possible to handle some tracebacks in special way, 
without try/execept all the code.

Tim



More information about the Yum-devel mailing list