new kickstart work

[Chris Lumens]

As anyone who's been following Rawhide knows, kickstart has been
undergoing a whole lot of work recently.  This work has been a complete
rewrite of the kickstart file parser and data representation in anaconda
due to a couple realizations:

(1) anaconda and s-c-kickstart use completely different code bases.  The
     biggest problem here is that s-c-kickstart is falling farther and
     farther out of sync with anaconda as to what is supported and what's
     not.
(2) There are some long-standing bugs in kickstart that cannot be fixed
     because the current code is sort of tough to work with.  One example
     of this is post scripts in include files all get executed in the
     chroot environment, regardless of what you want.
(3) We don't have any validation tools right now besides writing a
     kickstart file and cramming it through anaconda to see if it works
     or not.
(4) Even within anaconda, there are multiple kickstart file parsers.
(5) s-c-kickstart doesn't understand all the options that kickstart
     supports so if you take an existing file and run it through the
     program, what you get out will have lots of data stripped (if
     it even reads in the file at all).

Okay, enough rationale.  My main idea was to create a single new
codebase that handles all the reading and writing of kickstart files and
to make that code generic enough to where it's not a pain to adapt it to
your uses.  Therefore, I present the new pykickstart package in Rawhide.
It's been in the works within anaconda for a couple weeks now but I have
finally broken it out into its own package so you can use it for your
own purposes.

As always, the documentation is a bit light at the moment but that will
be coming soon.  The code is pretty well commented so it should be
reasonably easy to follow, but here's an outline of the core:

- KickstartData is a class containing a variety of attributes that
   represents the kickstart file.  Wherever possible, things are
   represented in some real type instead of just a string.  There are
   a variety of other Kickstart*Data classes found in data.py.  These
   are meant to be put in the lists in KickstartData.

- KickstartParser is the central class.  It is essentially a state
   machine that transitions on seeing the various sections of the
   kickstart file.  Functions are run upon state transitions, and these
   functions may be overridden in a subclass of KickstartParser if you
   need specialized behavior.  The core function of readKickstart should
   be generic enough to never need overriding, unless you are doing
   something really crazy.  If it's not flexible enough, this is probably
   a bug on my part.

- KickstartHandlers deal with all the commands found in the command
   section of your kickstart file.  Each command has its own handling
   function that deals with the legal options for the command and sets
   values in KickstartData appropriately.  Again, you may subclass
   KickstartHandlers to do whatever you would like.  If you want to
   make your own subclass handlers, it is a good idea to call the
   superclass handler first to set KickstartData.  Then, do whatever
   you would like.

- We are using all sorts of features from OptionParser, which I am
   not going to go into here.  However, one of the nice features is
   the ability to mark options as deprecated.

- KickstartWriter takes a KickstartData object and spits out a file.
   It similarly has handlers for each command, though I haven't done
   nearly as much with it as I have with the front end.

So real quick:  how would you go about using all this stuff?  I'm glad
you asked.

 	from pykickstart.parser import *
 	from pykickstart.data import *

 	ksdata = KickstartData()
 	kshandlers = KickstartHandlers(ksdata)
 	ksparser = KickstartParser(ksdata, kshandlers)
 	ksparser.readKickstart("ks.cfg")

There you have it.  You've now got ksdata populated and ready for use.
Oh, you might also want to handle the various exceptions that can be
thrown.

How would you go about extending pykickstart for your own purposes?  I'm
going to save that for another long email.  Or, you can look at
kickstart.py in anaconda and see what's going on.  It's really not too
difficult.  I think this is going to result in being able to make a lot
of new stuff around kickstart pretty easily.  My first goal is getting
s-c-kickstart fixed up to use pykickstart (ugh, this is lots of work).
My second goal is making a ksvalidator.  That should be really simple.

Oh, and a warning.  This is all still in a lot of flux and before FC5, I
might totally rewrite parts of the API.  Nothing is stable yet and
shouldn't be taken as such.  Feel free to experiment with it, but
understand I might get a crazy idea and redo something.

So, thoughts?

- Chris