Fix #931:add 'actions' key support for YAML,keeping the existing 'children' key as a fallback#971
Fix #931:add 'actions' key support for YAML,keeping the existing 'children' key as a fallback#971SanjayS66 wants to merge 1 commit into
Conversation
…'children' key as a fallback Signed-off-by: SanjayS66 <sanjay702594@gmail.com>
1ab5606 to
4853baa
Compare
emersonknapp
left a comment
There was a problem hiding this comment.
I'm concerned that this is global, but children may not always == actions. It is equivalent for <group> but are there other cases where XML frontend uses children but the Python API doesn't call them actions?
emersonknapp
left a comment
There was a problem hiding this comment.
Okay I did an investigation on this and found that children is used in
GroupAction:kwargs['actions'] = children- (launch_ros)
TimerAction:kwargs['actions'] = children ForEach: Python API isfunction=, children parsed into a closureForLoop: same
In all these contexts, the relevant children are indeed Actions. I believe that it would be semantically nonsensical for an action to provide an interface that exposes actions as a YAML input and also calls entity.children. In any case, the assert_entity_completely_parsed would catch that one of the two was never read.
This seems good to me, thanks for the contribution.
|
Pulls: #971 |
Description
This PR adds support for YAML to accept 'actions' key to match the Python API, while continuing to have 'children' as a fallback to not break the existing usage.The ValueError message in the parser has also been updated to reflect both 'actions' and 'children' as valid keys
Fixes #931
Is this user-facing behavior change?
yes. User can now use 'actions' to define nested entities.Existing files using 'children' will continue to work as that children is added as fallback.Error message also has been updated to reflect support for both actions and children keys.
Did you use Generative AI?
No
Additional Information