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