[augeas-devel] Simple pyGTK Augeas viewer

[David Lutterkort]

On Tue, 2009-03-10 at 19:23 -0400, David Malcolm wrote:
> On Sun, 2009-03-08 at 20:30 -0700, David Lutterkort wrote:
> > On Sat, 2009-03-07 at 12:33 -0500, David Malcolm wrote:
> > > I was playing around with the python augeas bindings.
> > > 
> > > Attached is a simple pygtk app that lets you browse the full Augeas
> > > tree, in a two column Path/Value treeview.
> > 
> > Nice :) Unfortunately, this segfaults for me on an F10 machine somewhere
> > in _ctypes.so while its callin free(). Not sure what that is - an error
> > in the bindings ?
> 
> Not sure.  For reference, it's working for me with these rpms:
> augeas-devel-0.3.6-1.fc10.i386
> python-augeas-0.3.0-1.fc10.noarch
> augeas-libs-0.3.6-1.fc10.i386
> augeas-0.3.6-1.fc10.i386
> augeas-debuginfo-0.3.3-1.fc10.i386

Found the problem (this is with augeas-0.4.2, but will cause trouble
with any Augeas >= 0.4.0): the very  first call to populate_tree_store
is with a path of "/", resulting in a call to aug.match("//*") which
since Augeas 0.4.0 means 'any node anywhere in the tree', following the
XPath syntax.

If you change populate_tree_store to (sorry for the non-diff):

            def populate_tree_store(self, path, parent_iter):
                iter = self.treestore.append(parent_iter, [path, self.aug.get(path)])
                if path == "/":
                    path = ""
                try:
                    child_paths = self.aug.match(path+'/*')
                except RuntimeError:
                    return
                for path in child_paths:
                    self.populate_tree_store(path, iter),

But even with that, it still dies 3 out of 4 times somewhere deep in the
guts of python - but at leasy I've seen the UI ;)

> > > It's very simplistic: it gathers data from the full tree on startup,
> > > rather than trying to do it on demand, so it takes a few seconds to
> > > start on my laptop.
> > 
> > It would  be really nice to build this out more, e.g. only query as much
> > of the tree as needed, make values editable etc. Even just as a viewer
> > it would be really helpful in letting people understand more clearly
> > what the tree for a given file looks like.
> 
> I had a go at looking up the text file and showing that in the UI.
> Potentially could show diffs as well.
> 
> Is there any way to get at the precise region of the file corresponding
> to a given node?  e.g. for "syntax" highlighting.

That would be very neat - I have that information internally when I
parse the file, but I don't keep it around, and it's definitely not
exposed in the API.

David