[augeas-devel] Re: using defnode to add new nodes

[Kjetil Torgrim Homme]

On Tue, 2009-06-16 at 18:12 +0000, David Lutterkort wrote:
> On Tue, 2009-06-16 at 11:08 +0200, Kjetil Torgrim Homme wrote:
> > David Lutterkort <lutter at redhat.com> writes:
> > > The path you use will only find the service-name node for 'foo' if it
> > > has a protocol child set to 'tcp' - but the set that defnode does, does
> > > not create a protocol child. With that, you wind up with a defvar with a
> > > path that matches no nodes, and var contains the empty node set.
> > 
> > exactly.  the bug is that it doesn't add the new node to the node set.
> > after all, it's not a dynamic evaluation, so adding it statically
> > should work.
> 
> Variables are not changed once they have been defined - i.e., when you
> do 'defvar var expr', expr is evaluated and the result is assigned to
> var (just like in any other language). After that, the value of var is
> not changed.

right.  I'm not suggesting that the variable defined by defnode is
changed *after* defnode returns.  I'm just suggesting that the node
defnode creates is included in the node list returned.

> > I dare say it's expected and wanted behaviour.  an
> > orphaned node is not very useful.
> 
> The node isn't orphaned, it's in the tree, it's just that the path
> expression you use in defnode doesn't match anything, even after the
> set, since the new node doesn't have a 'protocol' child yet.

how come the node is instantiated and initialised, then?  if it's not
matching, why should it?  the node is *worse* than orphaned, since it
is not refered to by the node set (basically inaccessible unless you
jump some hoops), and will screw up a save operation.

IMHO, for consistency, you either need to drop that instantiation, or
you need to include the node in the result set.  obviously the latter is
more useful.

> > I do not want "if" statements, "if" statements are fragile and you can
> > easily get uncovered cases etc.  I want a declarative language, and
> > defnode + XPath is *almost* there for many uses.
> 
> I don't think that defnode is a good base for a declarative way to
> modify the tree. For that, you want a way to say "here is subtree and
> the place where it should appear in the overall tree"; the trouble in
> general lies with defining the place where the subtree should appear -
> in your example, that place depends on two nodes (service-name = 'foo'
> and service-name/protocol = 'tcp'), but there's no reason why that
> couldn't depend on even more complex conditions on the structure of the
> tree.

I'm sure it's possible to come up with problematic examples, and I
encourage you to do so, so that we can discuss how Augeas is to be
*used*.  a little (but not much) more tricky example: defnode doesn't
work with the hosts lens, since it creates hosts/N/ rather than
hosts[N].

        augtool> print '/files/etc/hosts/*/*[../ipaddr = "127.0.0.1"]'
        /files/etc/hosts/1/ipaddr = "127.0.0.1"
        /files/etc/hosts/1/canonical = "localhost.localdomain"
        /files/etc/hosts/1/alias[1] = "localhost"
        /files/etc/hosts/1/alias[2] = "localhost"
        augtool> defnode host '/files/etc/hosts/*/*[../ipaddr = "127.0.0.1"]'
        Failed

first of all, such inconsistencies across lenses should be fixed.
secondly, I think it's quite reasonable that in the non-matching case,
defnode would create a new object at the level of the first wildcard.
in either case I would like to be able to say

        set $host/ipaddr 127.0.0.1
        set $host/canonical localhost
        set $host/alias[1] localhost.localdomain

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game