'ros2 interface show' doesn't work when message file is in sub-directory

[bijoua29]

Bug report

Required Info:

• Operating System:
  • Ubuntu 22.04,
• Installation type:
  • 'rolling' binaries
• Version or commit hash:
  • N/A
• DDS implementation:
  • default Fast-RTPS
• Client library (if applicable):
  • N/A

Steps to reproduce issue

I was debating whether to put this under the feature request. Regardless, here's the issue. My directory structure for my ros2 message file is my_interfaces/msg/ControllerState/State.msg.

Call 'ros2 interface show my_interfaces/msg/State'

Expected behavior

bool enabled

Actual behavior

Error processing '// generated from rosidl_adapter/resource/msg.idl.em' of 'my_interfaces/State': '//'
Traceback (most recent call last):
  File "/opt/ros/rolling/bin/ros2", line 33, in <module>
    sys.exit(load_entry_point('ros2cli==0.19.0', 'console_scripts', 'ros2')())
  File "/opt/ros/rolling/lib/python3.10/site-packages/ros2cli/cli.py", line 89, in main
    rc = extension.main(parser=parser, args=args)
  File "/opt/ros/rolling/lib/python3.10/site-packages/ros2interface/command/interface.py", line 35, in main
    return extension.main(args=args)
  File "/opt/ros/rolling/lib/python3.10/site-packages/ros2interface/verb/show.py", line 201, in main
    _show_interface(
  File "/opt/ros/rolling/lib/python3.10/site-packages/ros2interface/verb/show.py", line 148, in _show_interface
    for line in _get_interface_lines(interface_identifier):
  File "/opt/ros/rolling/lib/python3.10/site-packages/ros2interface/verb/show.py", line 116, in _get_interface_lines
    yield InterfaceTextLine(
  File "/opt/ros/rolling/lib/python3.10/site-packages/ros2interface/verb/show.py", line 43, in __init__
    msg_spec = parse_message_string(
  File "/opt/ros/rolling/local/lib/python3.10/dist-packages/rosidl_adapter/parser.py", line 520, in parse_message_string
    Type(type_string, context_package_name=pkg_name),
  File "/opt/ros/rolling/local/lib/python3.10/dist-packages/rosidl_adapter/parser.py", line 277, in __init__
    super(Type, self).__init__(
  File "/opt/ros/rolling/local/lib/python3.10/dist-packages/rosidl_adapter/parser.py", line 190, in __init__
    raise InvalidResourceName(type_string)
rosidl_adapter.parser.InvalidResourceName: //

Additional information

If the State.msg is not in the ControllerState sub-directory, I do not get this error. It looks like all the message files need to be in the top-level 'msg' directory. I don't remember anywhere where it states that the msg files have to reside in a flat directory structure. This doesn't allow a more intuitive organization of message files in a directory structure.

[clalancette]

This is related to #213 (it is not exactly the same, but we discussed some of the same issues there). In short, this is currently not supported. We probably won't look into it anytime soon, but if you'd like to take a stab at it we'd be happy to review patches.

[clalancette]

This is related to #213 (it is not exactly the same, but we discussed some of the same issues there). In short, this is currently not supported. We probably won't look into it anytime soon, but if you'd like to take a stab at it we'd be happy to review patches.

Oh, actually, I'm wrong. This is exactly the same as #213, so closing it as such.

[bijoua29]

@clalancette Thanks for the response. I understand the issue with the flat namespace versus a folder structure. It just restricts the number of messages you would want to put in one namespace before the folder becomes unbearably large when you are looking for a specific message.

I feel like this could have been addressed during the original design phase and now it's probably too hard to add it after the fact without some breaking change that would affect everyone. In any case, I wouldn't know where to start. If I would change it, I would have the namespace reflect the folder structure - then msg files could have the same name as long as they would be in separate folders. I don't know what the implications of this would be though. It doesn't sound like an easy fix either otherwise someone would have attempted this already. I guess for now I will use a flat folder structure and organize by separate packages instead of the preferable folder structure within a package.