Rename node-related parameters

[jacobperron]

The 'node-' prefix seems redundant since the attribute is part of a "node" tag.
Add a deprecation warning in case the old name is used.

I couldn't find a reason why 'node-name' was preferred in #73.
I'm suggesting in this PR that we change it 'name', which seems more intuitive for me, especially coming from ROS 1.

[jacobperron]

I also just noticed that the migration guide uses the attribute "name", which is currently inconsistent with the implementation.

[hidmic]

which is currently inconsistent with the implementation.

You're absolutely right, good catch.

[hidmic]

@jacobperron hmm, while this is a fine patch, it grows the gap between Python and markup-based launch files. This is something we've discussed with @ivanpauno several times, how detrimental to standardization is the fact that launch frontend parsing support allows one to depart from the original action "signature". IMHO, we should apply this exact same change to the Node action constructor itself and the parsing function should just use that. WDYT?

[ivanpauno]

The problem with changing the Node signature is that it breaks API in a confusing way:
if somebody was using name to specify the executable name, they will have a surprise when that's now used as node name.
I think will should keep XML attributes as close as possible to Python constructor arguments.

[hidmic]

That is also true. But doing so in XML/YAML only but not in Python makes it worst IMO.

[jacobperron]

I agree that this change should happen in the Node constructor, keeping the signature the same as the front-end. I'll do this if there's a consensus to go ahead with this change.

The problem with changing the Node signature is that it breaks API in a confusing way:
if somebody was using name to specify the executable name, they will have a surprise when that's now used as node name.

Yeah, this is a problem. IMO, it seems like a good thing to change long term. In the short-term, we can document the behavior change in the release notes and on whatever documentation exists for launch_ros (note, besides the API docstrings, I only found mention of the "name" attribute in the migration guide and it is already assuming the behavior I expect).

I also understand if there's consensus to leave the implementation as-is in order to avoid breaking the existing behavior.

[ivanpauno]

I think that the API break is reasonable.
To avoid breaking user launch files, node_name can be deprecated with a warning.
The users that were using name will have to check the release notes to understand the problem (though I expect not much users using it).
We should also merge the argument name change together with a PR updating the release notes. If not, we will forget later.

If @wjwwood and @hidmic are also ok with breaking API, I think it's fine.

[wjwwood]

👍 to breaking API to make it make sense, and 👍 for updating the documentation and release notes simultaneously.

[jacobperron]

Thanks for the input, all. I'm on it 😎

[jacobperron]

@hidmic @ivanpauno I've reverted the 'name' overriding in the parser (45d4992) and added new Node parameters for name and namespace (827042b), deprecating the old parameters. I've also added a new Node param exec_name for setting the process name (e7e1325)

[ivanpauno]

Left some minimal comments.
It would be good to check if something has to be updated in demos/examples/tutorials.

[jacobperron]

It would be good to check if something has to be updated in demos/examples/tutorials.

Good idea, I'll open up PRs connecting to this for instances I find.

[jacobperron]

LifecylceNode has a required keyword argument named node_name. I've just patched how it is passed to it's parent constructor (586e09c), but what do you think about also renaming it's argument to name? This would be a harder API break, since we would would have to introduce a new argument name that is required.

[jacobperron]

Adding to Foxy release notes: ros2/ros2_documentation#522

[ivanpauno]

LifecylceNode has a required keyword argument named node_name. I've just patched how it is passed to it's parent constructor (586e09c), but what do you think about also renaming it's argument to name? This would be a harder API break, since we would would have to introduce a new argument name that is required.

I think that if we're going to do the change, it makes sense to rename all the node_* of any action/description (LifecycleNode, ComposableNodeContainer, ComposableNode, ...).
To avoid that hard API break in that case, the following can be done:

  def __init__(self, *, name: Optional[Text] = None, node_name: Optional[Text] = None, **kwargs) -> None:

If node_name is passed, a warning is showed.
If both name and node_name are passed, an error is raised.
If only name is passed, we're happy.

In another release, node_name can be removed and name be required.

[jacobperron]

If node_name is passed, a warning is showed.
If both name and node_name are passed, an error is raised.
If only name is passed, we're happy.

Also, if both are None, an error raised. I don't think the LifecycleNode action will work otherwise.

I can do this.

[jacobperron]

I've also deprecated the node_name parameter for LifecycleNode (09aa4c5) and updated the connected demos PR.

[ivanpauno]

LGTM with @wjwwood and @hidmic 👍

[hidmic]

LGTM!

BTW I figure you chose not to add an Optional type annotation for some constructor arguments where a None default is used to convey that argument it's mandatory, but I'd expect mypy to complain.

[jacobperron]

• Linux
• Linux-aarch64
• macOS
• Windows

The same test failures are occurring on the latest nightly builds.

[hidmic]

Overall LGTM, pending green CI

[ivanpauno]

@jacobperron is this ready to be merged?

[jacobperron]

I was hesitating due to the CI failures. I've retriggered CI.

[nuclearsandwich]

@jacobperron I haven't completed the first CI test but in local research ros2/ci#399 is a workaround for the installation paths which should allow the tests to run.