On Wed, 2013-12-04 at 12:50 -0700, Dmitry S. Makovey wrote: > On 12/04/2013 10:44 AM, James Antill wrote: > > On Tue, 2013-12-03 at 15:31 -0700, Dmitry S. Makovey wrote: > >> Hi, > >> > >> I'm developing a plugin and one annoyance I found is that current way of > >> exiting from yum is via "raise PluginYumExit(...)" which makes yum > >> return exit code 1 - same as when error occurs. > > > > There is also the "base.exit_code = foo" API, however that is also for > > non-zero errors. > > > >> Without resorting to > >> "sys.exit(0)" is there another way to gracefully stop Yum execution? > > > > No, not really. > > too bad :( Any chance of integrating optional exit code into > PluginYumExit code and the exception handling routines? ;) I can tinker > a bit to provide a patch if you wish.
I'm not dying to do that, but note that raising that exception doesn't buy you much over just calling sys.exit() _anyway_. > > All of the above, and a few other reasons, is why I'd generally > > recommend against making/using plugins ... it's much easier to integrate > > features into core and have them all work together well. > > What problems are you trying to solve? > > My plugin is a "bridge" between "CPacMan" tool we use for central cerver > management (acts opposite to spacewalk - more ansible-like ssh-push > mechanism with no agents on remote host). So whenever --servername=... > is supplied on yum's command line plugin kicks in and schedules install > transaction on specified server (which is to be followed up with manual > execution of transaction). Since at that point I'm "hijacking" yum's > dependency resolution, fetching, RHN interaction, funky plugins etc. > capabilities I really have to ditch last portion of workflow - the > actual installation, verification and cleanup. I just grab compiled > transaction and record it for later use with whatever server was > specified. This arrangement seemed fairly natural and straight-forward > for our team as there was only fewer tools to use in the process of > package roll-out. I did not use "save transaction" mechanism in yum > (since it was not available at the time I've started). Plugin also > auto-injects repos depending on server class definition etc. (something > like RHN plugin, but not quite) but that's another story. > > Make long story short - I looked at calling yum externally or using it's > API and came to conclusion that it would be much more work to use yum > as an external tool (API or otherwise) vs embedding smaller piece of > code into yum via plugin. At the moment I'm [re-]evaluating my > assumptions gearing up for the rewrite of CPacMan etc. I would highly recommend you do it the other way, have python code you own be the top level and create YumBase() instances/etc. ... then call whichever functions you want (enabling/disabling other plugins) and exit when you want. Look at the latest yum-cron for an ok skeleton. The "main" reason to use a plugin instead of calling the API directly is that you get all the yum UI for free, and it's a little bit easier to get something going for small enhancements. The former doesn't apply to you, and esp. with yum-cron to look at the later doesn't really either. _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
