:children group syntax

[Dan Mick]

Why does :children exist?  Why couldn't it be the case that groups of groups just recurse on their components, expanding as they go?

[Brian Coca]

its a way to distinguish between groups and hosts, as both entries can
look the same.



--
Brian Coca

[Dan Mick]

Well of course, but why?  Why is it necessary to distinguish?  "If group, expand group; if not, don't"

[Brian Coca]

yes, how do you know if it is a group? it might be defined below, or
it might be a host.


--
Brian Coca

[Dan Mick]

you know if it's a group if it has a name that matches a defined group name.  Are you saying it's solely to allow forward references to groups?  If so, isn't it an attribute of the child name itself that it refers to a group, and not "the supergroup can only contain children"?

i.e. any of these make more sense to me than the current definition:

1) expand if a name refers to a known group; otherwise don't expand (doesn't handle forwards)
2) make two passes through inventory files to handle forwards (might be tricky/undoable with dynamic inventory)
3) tag each groupname within the group:

[groupofgroups]
host1
group1:group

The way it is now, effectively defining every member of the group as a group with the unintuitive "children" on the enclosing group, seems the least intuitive of all, and unlike every other such tool.

[Brian Coca]

my initial proposal was require @ as the start of group names, many
ways to do it, this is what the original author came up with and
avoids multiple passes or non forward working groups.

Even better, you can create a inventory plugin that implements any
format you want, but for now there are no plans to change the current
format as its been the same for roughly 3yrs and most people are fine
with it.


--
Brian Coca

[Dan Mick]

Not suggesting change, just trying to understand rationale.  I guess it's the way it is because it's the way it is.