On Mon, 2011-10-24 at 12:59 -0700, John Reiser wrote:
> > # New, expanded template language
> > - Nearly all the image building happens in the templates
> > - New commands to help simplify/clarify the build process:
> > install, mkdir, replace, append, hardlink, symlink,
> > copy, copyif, move, moveif, remove, chmod, gconfset,
> > installpkg, removepkg, removefrom, run_pkg_transaction,
> > treeinfo, installkernel, installinitrd, runcmd
> [snip]
> > - More code should move into the templates over time.
>
> I had some problems with the new templating during the development
> of treebuilder branch. I could not figure out what was happening,
> documentation was sparse, and the result was just "wait."
After you asked last time, I improved the exception handling and added a
bunch of docstrings for the template commands. (See e.g. commits
318c843e and 473f01c6.)
Exceptions currently give you the exact command and error on the
console, like this:
template command error in x86.tmpl:
install HERP DERP
IOError: nothing matching /srv/[...]/installroot/HERP in /
The full traceback, with associated line number, is written to the log:
: template line 10: install HERP DERP
: template command error in x86.tmpl:
: install HERP DERP
: IOError: nothing matching /srv/[...]/installroot/HERP in /
: Traceback (most recent call last):
: File "[...]/ltmpl.py", line 175, in install
: for src in rglob(self._in(srcglob), fatal=True):
: File "[...]/ltmpl.py", line 93, in rglob
: raise IOError, "nothing matching %s in %s" % (pathname, root)
: IOError: nothing matching /srv/[...]/installroot/HERP in /
I also added comments to the templates themselves to try to explain
what's going on in there. Oh, and there's a 'log' command, so you can
make the templates write info into the logs.
Templates do not stop on errors, but you can enable that behavior by
setting 'fatalerrors' to True in treebuilder.py.
Also, if you wanted to end a template early, a simple <% return %> would
do. You might want to read the Mako documentation to better understand
how mako templates work: http://www.makotemplates.org/
I'll note here that the PPC secondary-arch team is currently using
treebuilder to make their images and it's working pretty well for them.
> If the template language cannot detect and report errors (or
> "policy violations") by line number,
As above, you get the exact template line number - although that's the
*parsed* template, which can be longer than the input (due to looping
and things like that). Still, it really shouldn't be that hard to figure
out the source of the problem, given the exact command being executed.
If there's something specific that you couldn't understand, feel free to
ask, but "I had some problems and I couldn't figure out what was going
on" isn't something I can act on to improve.
> or cannot be debugged/traced/breakpointed/etc.,
I don't consider the lack of debuggers or breakpoints a show-stopper
(you ever set a breakpoint on a loop in bash?) but in theory you could
use the Python debugger on Mako modules; you might try asking the Mako
developers about it if you really must pursue that further.
> then I consider that to be a significant disadvantage.
Compared to what? Previous versions of lorax also use mako to generate
the templates; I just added more commands, consolidated all the command
parsing in one python class (LoraxTemplateRunner() in ltmpl.py), and
added docstrings (with examples) for every command available.
I think, on the balance, the advantages outweigh the perceived
disadvantages.
> What is the current status of new templates with regard to
> detecting and reporting errors, debugging, and other aspects
> of Usability, Reliability, and Supportability?
I hope I've explained the current state of these things above. If anyone
has further questions, or ideas for specific improvements, I'd really
like to hear them.
-w
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
