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