Re: request: yumvar plugin hook

On Mon, Apr 16, 2007 at 11:21:24PM -0400, 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()

the problem here is that the 'config' plugin is already
called from
plugins.py. This would mean that the config plugin is called
twice, and,
most probably, lots of config plugins are going to be
unhappy about
that.

For my uses, simply moving the init plugin up a few lines
works fine.
Not sure that many plugins need the repo configs simply
because they
would probably run into the same issues I did.

Jeremy, James, I was talking to Seth last night on irc and
he said to
ping you guys about this since he is sort of offline.
--
Michael
_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

I would like to request a new yum plugin hook: yumvars_hook.
Run
self.plugins.run('yumvars') right after 
    doConfigSetup(...):
        ...
        self.conf = config.readMainConfig(startupconf)
        self.plugins.run('yumvars')

I believe it should re-use the same conduit as the
init_hook.

The reason for this is for future compatibility. Right now,
I use an
init_hook, and I have to repo.yumvar.update() after I add a
yumvar, as
well as manually reprocess the mirrorlist variable. If, in
the future,
the mirrorlist is processed differently (as I just found out
is the case
for at least yum 2.4.3, so it may be different in the future
as well), I
wont have to do anything special.

I would be able to make a plugin that is compatible with a
wide range of
yum versions by exiting early in the init_hook if the plugin
api is new
enough.

Thanks,
Michael
_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

On Sat, Apr 07, 2007 at 04:57:28PM -0500, Michael E Brown
wrote:
> I would like to request a new yum plugin hook:
yumvars_hook. Run
> self.plugins.run('yumvars') right after 
>     doConfigSetup(...):
>         ...
>         self.conf = config.readMainConfig(startupconf)
>         self.plugins.run('yumvars')
> 
> I believe it should re-use the same conduit as the
init_hook.
> 
> The reason for this is for future compatibility. Right
now, I use an
> init_hook, and I have to repo.yumvar.update() after I
add a yumvar, as
> well as manually reprocess the mirrorlist variable. If,
in the future,
> the mirrorlist is processed differently (as I just
found out is the case
> for at least yum 2.4.3, so it may be different in the
future as well), I
> wont have to do anything special.
> 
> I would be able to make a plugin that is compatible
with a wide range of
> yum versions by exiting early in the init_hook if the
plugin api is new

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=
236478

This bugzilla defect would be fixed if I had the yumvar hook
outlined
above. 

My plugin becomes:

def yumvar_hook(conduit):
    conf.yumvar["dellsysidpluginver"] = version
    try:
        sysid = getSystemId()
        conf.yumvar["sys_ven_id"] =
"0x1028"  # hex
        conf.yumvar["sys_dev_id"] =
"0x%04x" % sysid
    except:
        pass

def init_hook(conduit):
    if YUM_API_VERSION >= yumvars-hook-api-version:
        return

    # do a bunch of backwards compat stuff

--
Michael
_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

On Mon, 2007-04-16 at 12:07 -0500, Michael E Brown wrote:
> On Sat, Apr 07, 2007 at 04:57:28PM -0500, Michael E
Brown wrote:
> > I would like to request a new yum plugin hook:
yumvars_hook. Run
> > self.plugins.run('yumvars') right after 
> >     doConfigSetup(...):
> >         ...
> >         self.conf =
config.readMainConfig(startupconf)
> >         self.plugins.run('yumvars')
> > 
> > I believe it should re-use the same conduit as the
init_hook.
> > 
> > The reason for this is for future compatibility.
Right now, I use an
> > init_hook, and I have to repo.yumvar.update()
after I add a yumvar, as
> > well as manually reprocess the mirrorlist
variable. If, in the future,
> > the mirrorlist is processed differently (as I just
found out is the case
> > for at least yum 2.4.3, so it may be different in
the future as well), I
> > wont have to do anything special.
> > 
> > I would be able to make a plugin that is
compatible with a wide range of
> > yum versions by exiting early in the init_hook if
the plugin api is new
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=
236478
> 
> This bugzilla defect would be fixed if I had the yumvar
hook outlined
> above. 
> 

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?
-sv


_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

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-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel