[Yum-devel] request: yumvar plugin hook

[Tim Lauridsen]

seth vidal wrote:
> On Mon, 2007-04-16 at 23:04 -0400, seth vidal wrote:
>   
>> okay, I'm looking at this code and other spots and two things pop into
>> mind:
>>
>> 1. it seems like it might make more sense to have a pre_config_hook and
>> a post_config_hook so people could molest the config obj before and
>> after its setup - that would cover yumvars.
>>
>> 2. odd that we're not using the config slot anywhere at all, even though
>> it appears to be defined in plugins.py. it might be best to make these
>> lines in __init__.py:
>>
>>         self.conf = config.readMainConfig(startupconf)
>>         self.yumvar = self.conf.yumvar
>>         self.getReposFromConfig()
>>
>> into:
>>
>>         self.conf = config.readMainConfig(startupconf)
>>         self.plugins.run('config')
>>         self.yumvar = self.conf.yumvar
>>         self.getReposFromConfig()
>>
>> Then we cover the case needed and we're just using what we already have.
>>
>> thoughts?
>>     
>
> and we'd need to add something like
> getOpt()
> setOpt()
> into ConfigPluginConduit() in plugins.py so that a plugin dev can do:
>   thisopt = conduit.getOpt('yumvars')
>   mydata = some_munge_of(thisopt)
>   conduit.setOpt('yumvars', mydata)
>
> as pseudo-code example
>
> does that make sense?
>
> -sv
>
>
> _______________________________________________
> Yum-devel mailing list
> Yum-devel at linux.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
>   
Make perfect sense to me.
While we are changing the the plugin conduit, i maybe is an idea to add 
a getBase(), some plugins need to work with the
YumBase object to do magic tricks, this is currently done by 
conduit._base, this is a private var and should not be messed with 
directly from a plugin.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070417/f869dc65/attachment.htm