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
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
