[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