-
Notifications
You must be signed in to change notification settings - Fork 91
Description
Feature request
This applies to both launch and launch_ros, but it is more relevant for launch_ros, since it has the main user-facing/ROS-specific launch actions.
Feature description
When using the Python launch API directly, the names of the arguments are documented in the constructor docstring. For example, see launch_ros.actions.Node.__init__(). It makes sense to expect the user to rely on that, and this can easily be part of automatically-generated API docs (e.g., using rosdoc2).
However, when using the YAML or XML frontends, the names of the arguments might differ from the underlying Python class constructor. See: #253 (comment). For example:
launch_ros.actions.Node.__init__()hasros_arguments:ros_arguments: Optional[Iterable[SomeSubstitutionsType]] = None, - but the corresponding frontend argument is
ros_args:ros_args = entity.get_attr('ros_args', optional=True)
This is not documented anywhere. While this might be part of some examples on docs.ros.org, it should be part of some sort of documentation.
Implementation considerations
Possible solutions:
- Change frontend argument names to be the same as the corresponding Python class constructor arguments
- I think it's just generally accepted, so I'll leave this out
- Add some sort of Python annotation so that the names can be automatically parsed and included in the (
launch_ros) API docs- Probably feasible, but uncertain; would require some work
- Manually document the frontend argument names in the top-level Python class OR Python class constructor docstring
- Feels weird to expect users to look at the Python action class docs to find the names of the frontend arguments
- Manually document the frontend argument names of the
launch_rosactions in a document underlaunch_ros/doc/and include in API docs generated byrosdoc2, similar to whatlaunchhas- API docs are accessible from the index.ros.org page for the
launch_ros: https://docs.ros.org/en/rolling/p/launch_ros/ - This is the simplest solution
- However, the docs would need to be updated (manually) if anything changes, and having this documentation a bit farther away from the actual code (compared to Python docstring) makes this slightly more of a hassle
- The argument names concern the launch frontends (
launch_xml/launch_yaml), but all the logic is in the underlying Python class (launch_ros), so it wouldn't make sense to document this in the actual frontend packages. One thing to point out: while the Python action class defines the names of the arguments for the frontends, the names are the same for all frontends, and the Python action implementation has no idea that there is a YAML frontend and an XML frontend. So these are all just "names for the frontends." The user-facing document could mention "the YAML and XML frontends" to make it simpler for users, but it doesn't have to. - This should be linked to from one or more relevant pages in docs.ros.org:
- API docs are accessible from the index.ros.org page for the