Show IDL interfaces in their original format

[Old-Ding]

Description

rosidl_runtime_py.get_interface_path() returns the installed source format: .msg, .srv, or .action when present, otherwise .idl. ros2 interface show currently sends every returned file through the ROS message line parser, so an IDL module declaration raises InvalidResourceName.

Resolve the interface path once in the show layer. Preserve the existing recursive expansion path for ROS interface files, while printing .idl files in their original format as requested by the maintainers. Preserve the CLI trailing-newline behavior for IDL files with or without a source trailing newline.

Fixes #780.

Is this user-facing behavior change?

Yes. ros2 interface show now displays interfaces authored directly as IDL instead of failing on the first IDL declaration. ROS .msg, .srv, and .action output is unchanged.

Did you use Generative AI?

Yes. OpenAI Codex assisted with root-cause analysis and preparing the focused code and regression tests. I reviewed the diff and verification results.

Additional Information

Local verification:

• the regression test first reproduced the issue with the real Rolling rosidl_adapter parser: module was rejected as an invalid message name
• two focused unit tests now pass, covering unchanged .msg output and raw .idl output with and without a source trailing newline
• ament_flake8, ament_pep257, and ament_copyright passed for all 16 ros2interface files
• compileall and git diff --check passed

The repository's launch-based CLI integration test is skipped on Windows by its existing module-level marker. The focused tests used the real show.py and Rolling rosidl_adapter; only the unrelated resource-discovery API was stubbed because the local Windows environment lacks the compiled rosidl_buffer extension. Repository CI covers the full ROS installation path.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[fujitatomoya]

@Old-Ding same here, can you provide the test result for this? either log or screen capture?

[fujitatomoya]

this is just a test for API, i think unit test for actually idl types should be added to ros2cli_test_interfaces.

[Old-Ding]

Thank you. I replaced the temporary API-only test in 1aea823 with real interfaces in ros2cli_test_interfaces:

• IdlOnly.idl and test_show_idl_message exercise ros2 interface show for a top-level IDL message.
• ShortVariedIdlNested.msg and test_show_message_with_idl_nested_type exercise a .msg parent whose nested type is IDL, and assert the recursive tab indentation on every IDL line.

These are CLI integration tests, rather than a mocked get_interface_path unit test. I have completed static validation locally (python -m compileall and git diff --check), but this machine has no ROS build environment and no ROS CI job has been scheduled for the new head yet. I will provide the actual ROS test result once the build is available.

[Old-Ding]

Update with the requested ROS test result: https://github.com/Old-Ding/ros2cli/actions/runs/29411539491

I built the current PR head in an Ubuntu ROS Rolling container and ran the ros2interface test suite. The run built 3 packages; its test/test_cli.py launch test passed, and colcon test-result --verbose reports 5 tests, 0 errors, 0 failures, 0 skipped. This covers the two new real-IDL CLI cases in that test file.

[fujitatomoya]

i think this just displays whatever format the original is in. but it's a UX regression relative to what users get for .msg, where the whole point of interface show is that you see the full recursive structure without opening more files. i think recursive approach or consideration is completely off from this PR.

and what if the case with " .msg parent with an .idl-only nested type"?
the new IDL branch ignores indent_level (and the comment flags) entirely, raw module/struct boilerplate lands un-indented, i think this prints ugly...

[Old-Ding]

Thank you. I agree that an unindented raw IDL block in a nested expansion is poor UX. In 1aea823, the raw-IDL branch now applies the existing indent_level recursively to every line. The new CLI integration test covers a .msg parent with an IDL-only nested type.

I kept the IDL body in its original format intentionally: the maintainer guidance in #780 is that ros2 interface show should display the original format because some IDL cannot be converted to .msg / .srv (#780 (comment)).

That decision means the raw IDL branch currently preserves IDL comments for both comment options. Applying --no-comments / --all-comments to raw IDL would require defining an IDL-specific transformation rather than displaying its source. Could you please confirm whether you want that new formatting behavior, or whether preserving raw IDL with correct recursive indentation is the intended scope for this PR?

[fujitatomoya]

@Old-Ding i will hold to review the rest of the PRs from you until i have answers for ros2/rcl#1323 (review) and #1256 (review) from you.

otherwise, be advised that your submissions and PRs are going to be considered to violate our Rules for AI-Assisted Contributions regarding unverified LLM-generated code or feedback. in that case, we will be closing these PRs.

[Old-Ding]

@fujitatomoya I have now addressed and verified the review points for this PR.

• The former API-only test was replaced with real ros2cli_test_interfaces IDL fixtures and CLI integration coverage.
• A .msg parent with an IDL-only nested type is covered, and each nested IDL line is indented through the existing recursive indent_level.
• Verification: https://github.com/Old-Ding/ros2cli/actions/runs/29411539491 — Ubuntu ROS Rolling build; ros2interface test suite passed with 5 tests, 0 errors, 0 failures, 0 skipped.

For the remaining question about applying --no-comments / --all-comments to raw IDL, I left an explicit request for the intended semantics in the inline discussion rather than inventing an IDL transformation. The validation workflow branch differs from PR head 1aea823 only by its workflow file, so it tested the same source. I will update that behavior once you confirm the desired UX.