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 <[EMAIL PROTECTED]> Red Hat
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
