I'm no python wiz, and so I'm seeking some advice about the expected style 
for writing yum plugins.

I now have a hacked together yum plugin partly written - using bits from 
several of the examples from yum-utils etc.

The initial idea was to specify that some packages should not be installed 
until some (specified in a config) date, it will also refuse consider 
those marked 'reboot' if the day-of-week doesn't match one in the 
plugin-config.  I may add other bits to do weird local stuff too.

Because I'm lazy I'm using the python ParseConfig library so my 
special-config file has those bracketed bits.  Here is the example config 
file I'm testing with atm:

--start-of-file--
# testing if we can exclude a kernel 'til some date in the future
[ kernels ]
pkgs :	kernel-2.6.18-8.1.8.el5.i686
 	kernel-devel-2.6.18-8.1.8.el5.i686
 	kernel-headers-2.6.18-8.1.8.el5.i686
# Don't apply 'til the 25th July
mindate : 2007-07-25
# Will need a reboot
reboot  : 1

# More tests, sadly the syntax for 'epoch' isn't very pretty...
[ local-cups ]
pkgs :	1:cups-1.2.4-11.5.1.sl5x.1.CMS.i386
 	1:cups-libs-1.2.4-11.5.1.sl5x.1.CMS.i386
# On that date the new stuff may be installed
mindate : 2007-07-30
# No reboots needed for these...
reboot  : 0
--end-of-file--

and with the plugin enabled (and pointed at that config) things like yum 
update won't consider the packages which have a mindate in the future.

I don't expect that this will be of much interest to anyone else but I'm 
wondering if there is a standard way to pick names for plugins/options etc 
to avoid future slashes?  Is there a good way to avoid name clashes for 
the variables?  currently I need to read some stuff in one _hook and use 
it else (in two different _hooks) so I'm using globals for the moment...

At the moment the plugin is called 'skip-notyet' (for no good reason, that 
WILL change), namespace in the /etc/yum/pluginconf.d/ .conf files is 
obviously fine so I've got:

[main]
enabled=1
RebootDay=1

in there but adding extra command-line arguments seems useful and I've 
currently got it adding two options:

     parser.add_option('--cms_skip_cond_file', dest='cms_skip_cond_file',
                       help='path to cms special config file')
     parser.add_option('--cms_applyanyway', action='store_true',
                       dest='cms_skip_cond_applyanyway',
                       help='apply updates even if set not to yet')

other than making the options very long can anyone suggest a good way to 
split the name-space to avoid possible future clashes?

I'm not yet sure if I want to have the plugin actually DO anything about
the reboot flag if packages with it set get installed/upgraded.

  -- Jon