[Yum-devel] Making plugins more reliable for non-cli users
James Antill
james.antill at redhat.com
Fri Dec 28 01:40:00 UTC 2007
On Thu, 2007-12-27 at 10:22 -0500, 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 other problem, from my POV, is that we only have two types ... and
that doesn't really express all the plugins want. I think we want at
least a TYPE_YUM ... which is only triggered from yum itself (Eg. yumex
loads TYPE_INTERACTIVE plugins, but tracebacks if you "import cli").
> 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
No, this sucks, IMO.
> 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]
This is basically a (set of[1]) hacks we'd have to reproduce
everywhere. It's not terrible as long as it becomes a single yum call
(or is done automatically via. a normal one).
> 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
This is good, but then I'm a sucker for fail early :).
> d) something else?
Another option is to have some wrapper code so the "common"[1] problems
produce a known exception ... and we just catch that and disable the
plugin in the yum.plugin.run() code.
Actually it would be good to at least have some wrapper that actually
says where the problem is coming from: Ie.
<traceback>
yum plugin Foo produced error: blah, you might be able to solve this
problem by disabling plugin Foo, or all plugins.
...so at least people have an idea what they can do to solve the problem
on their own.
[1] One problem being that it's not obvious all the things the plugins
will do wrong.
--
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20071227/216b977b/attachment.pgp
More information about the Yum-devel
mailing list