Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix problems when parsing a Command Substitution as a parameter value #137

Merged
merged 14 commits into from
Aug 4, 2020

Conversation

ivanpauno
Copy link
Member

Trying to address #136.
Related with #74.

Since #31, substitutions in parameter values are loaded like yaml. This is an issue with the Command substitution, because it is not possible to skip the yaml.load() done by the Node action when parsing the input parameters.

My proposal here is to add a Parameter class, which allows to specify the type of the parameter.
One of the options is to convert the result of the substitution like yaml.

Other things I would like to revisit after this:

  • Add a type attribute in launch frontend parameters, map them to the new API.
  • Maybe stop supporting to pass a dictionary in parameters Node argument. Or maybe, don't allow substitutions in them (How to tic-toc?).
  • Consolidate type_utils here with type_utils used in launch.frontend.
  • Drop support of union of types in launch.frontend.type_utils. Update parsing functions if necessary.
  • Revisit lists in XML frontend. Drop *-sep and support list written like in yaml?

@ivanpauno ivanpauno self-assigned this Mar 24, 2020
Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me, but I just glanced over the description and the new API. Still needs a thorough review from someone else.

test_launch_ros/test/test_launch_ros/actions/test_node.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/parameter.py Outdated Show resolved Hide resolved
@wjwwood
Copy link
Member

wjwwood commented Mar 24, 2020

Maybe stop supporting to pass a dictionary in parameters Node argument. Or maybe, don't allow substitutions in them (How to tic-toc?).

My instinct is to leave them, but I don't know for sure.

Copy link
Contributor

@hidmic hidmic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that conceptually this makes sense, though I don't love how nested parameters end up being specified. I left some comments.

launch_ros/launch_ros/actions/node.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/actions/node.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/parameter.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/parameter.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/parameters_type.py Show resolved Hide resolved
launch_ros/launch_ros/utilities/type_utils.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/utilities/type_utils.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/utilities/type_utils.py Outdated Show resolved Hide resolved
launch_ros/launch_ros/utilities/type_utils.py Outdated Show resolved Hide resolved
@ivanpauno
Copy link
Member Author

Rebased with master, I'm working in addressing comments.

@ivanpauno
Copy link
Member Author

ivanpauno commented Jul 13, 2020

I've created ros2/launch#438, to consolidate all type_utils in launch repo.
I still have to polish things up, but this is ready for a review again.

@ivanpauno ivanpauno requested a review from hidmic July 13, 2020 13:41
@hidmic
Copy link
Contributor

hidmic commented Jul 30, 2020

I have to review this, and we need to decide what to do with

<!-- TODO(hidmic): revisit after https://github.com/ros2/launch_ros/pull/137 gets merged -->

Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
@ivanpauno ivanpauno force-pushed the ivanpauno/fix-parameter-bad-interaction-frontend branch from ba69703 to 4fea16f Compare August 3, 2020 17:59
@ivanpauno
Copy link
Member Author

I have to review this, and we need to decide what to do with

<!-- TODO(hidmic): revisit after https://github.com/ros2/launch_ros/pull/137 gets merged -->

Those "qoute" can be avoided by explicitly passing the type.

@hidmic
Copy link
Contributor

hidmic commented Aug 3, 2020

Those "qoute" can be avoided by explicitly passing the type.

Yes, that's what I thought. Though I wonder if we should keep that test case to make sure XML special characters work.

launch_ros/launch_ros/parameter_descriptions.py Outdated Show resolved Hide resolved
<param name="param12" value=""/>
<param name="param12" value="''"/>
<param name="param13" value="$(var my_value)" type="str"/>
<param name="param14" value="'2', '5', '8'" value-sep=", " type="list_of_str"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ivanpauno should it be

Suggested change
<param name="param14" value="'2', '5', '8'" value-sep=", " type="list_of_str"/>
<param name="param14" value="2, 5, 8" value-sep=", " type="list_of_str"/>

instead, to actually make sure YAML rules won't get in the way? Same below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the expected output is ["'2'", "'5'", "'8'"], this is checking that YAML rules aren't used in the way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking that YAML rules are not used to parse a list, but not checking that YAML rules are not used for each element.

Copy link
Member Author

@ivanpauno ivanpauno Aug 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking that YAML rules are not used to parse a list, but not checking that YAML rules are not used for each element.

The first element is "'2'". If yaml rules were being used, the output would be '2'. This is checking that the output is "'2'".
If I make the change you ask for, the test won't pass.

Copy link
Contributor

@hidmic hidmic Aug 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I make the change you ask for, the test won't pass.

How so? Assuming both markup snippets and test expectations are adjusted, of course.

I don't mind keeping that expectation as-is. But I'd really like to make sure that:

<param name="test" value="1, 2, 3" value-sep=", " type="list_of_str"/>

effectively yields a list of strings.

Signed-off-by: Ivan Santiago Paunovic <[email protected]>

Co-authored-by: Michel Hidalgo <[email protected]>
@ivanpauno
Copy link
Member Author

Yes, that's what I thought. Though I wonder if we should keep that test case to make sure XML special characters work.

That's still being tested, I've only deleted the TODOs.

@ivanpauno ivanpauno requested a review from hidmic August 3, 2020 18:50
@ivanpauno
Copy link
Member Author

I've to re-release launch to make the Rpr checker happy.

Signed-off-by: Ivan Santiago Paunovic <[email protected]>
@ivanpauno
Copy link
Member Author

@ros-pull-request-builder retest this please

1 similar comment
@ivanpauno
Copy link
Member Author

@ros-pull-request-builder retest this please

@ivanpauno
Copy link
Member Author

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants