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

[Jeremy Katz]

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.

> 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.

There is a common API.  Unfortunately, plugin authors seem to take
liberties with what they think it entails ;-)

Jeremy