Add color output utilities and tests

[penww]

This is the first PR to introduce colorized output support for ROS 2 commands. Once the approach is aligned on and approved, I will proceed with adding color support to more commands.

Description

Add helpers for supporting color output for ros2cli.

• Add cross-platform ANSI color helpers via colorama.
• Support NO_COLOR and FORCE_COLOR env based switch control.
• Apply color to ros2node info output as a reference integration.

Fixes #1222

No color:

Is this user-facing behavior change?

Yes, the user can see color output as default.

Did you use Generative AI?

Assissted-by: Claude Code (Claude Sonnet 4.6)

Additional Information

• Draft PR and disscussion: feat: add optional colorized output support #1223
• NO_COLOR, FORCE_COLOR env spec for CLI: https://no-color.org, https://force-color.org

[mergify]

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

• Queue this pull request

[penww]

Hi @skyegalaxy, do you have suggestions for this PR?

[penww]

Hi @fujitatomoya, @kscottz, and @StefanFabian, I've moved the color support work to this PR. Thanks for all the valuable suggestions on #1223. I'd appreciate it if you could take a look and share any additional feedback or suggestions.

[kscottz]

Thanks @penww. Just a heads up it takes a week or two to get fresh PRs assigned through our regular meeting. We'll get you a review just as soon as is feasible.

[skyegalaxy]

lgtm. had meant to review this a while ago so thank you for your patience!

[fujitatomoya]

i am not inclined to take this PR especially with colorized default behavior and environmentatl variables.

i believe that with color disabled, everything prints with no escape codes at all, so the terminal renders it in whatever default foreground/background the user configured. that's the maximally safe behavior.
IMO, user's terminal configuration and themes are different and set up as user's preference. this would be problem for some users like blue on black is the notorious case?
and then, affected user needs to opt-out this via environmental variable to disable the colorized behavior from ros2cli.

i would suggest that restricting the palette actually used in commands to theme-safe choices (bold, cyan, green, yellow; avoid blue as primary, never black/white), and consider a --color flag? so that users aren't forced into env-var-only control. besides that, defaulting to off would be the most conservative option, i think.

[penww]

Hi @fujitatomoya, thanks for review. I agree that the default behavior and color choices need to be handled carefully.

For the default behavior, one important point is that on ROS Lyrical (Ubuntu 26.04 / Python 3.14), argparse-generated help and usage output is already color-enabled by default when the terminal supports it. Users will already see color in ros2 help/usage output. If command output is default-off while argparse help is default-on, the overall CLI experience can become inconsistent. (https://docs.python.org/3/library/argparse.html#color)

For the palette, I agree we should be conservative. The initial colors were chosen to stay visually close to Python argparse's colorized help style, but I understand the concern about specific colors such as blue on some terminal themes (BOLD_BLUE is better). I think the common utility can expose the basic color capabilities, while each command integration should be reviewed separately so the actual palette is conservative and theme-friendly.

I also think Python argparse is a useful reference point here. Its color support was added upstream after discussion and review, and it is now the default behavior in Python 3.14. (we can refer: python/cpython#130645)

That said, I do not want to be too strict about default-on behavior. If default-off, or an explicit --color/--no-color option or --color=auto|always|never, would be more acceptable for ros2cli, I am open to updating the PR in that direction.

Please let me know which default policy you would prefer, and I can adjust the PR accordingly.

[fujitatomoya]

If default-off, or an explicit --color/--no-color option or --color=auto|always|never, would be more acceptable for ros2cli, I am open to updating the PR in that direction.

i am still inclined to take this path, but let's hear more opinion here. thanks for being constructive, i really appreciate that.

[penww]

Hi @fujitatomoya, since no further opinions were raised, I've updated the PR based on your suggestion:

• Color output is now disabled by default
• Use --color flag to enable it for a single invocation
• Set ROS_COLOR_OUTPUT=1 to enable it persistently for the current shell session
• In both cases, color is only active when stdout is a TTY, so piped or redirected output is always clean

Also, if the community decides it's the right time in the future (e.g. when ROS Lyrical becomes the minimum supported distro and Python 3.14's argparse color is on by default), we can revisit and switch the default to on.

Could you take another look and let me know if there are any remaining concerns? Thanks!

[fujitatomoya]

@penww thanks for being patient on this.

one minor concern.

Set ROS_COLOR_OUTPUT=1 to enable it persistently for the current shell session

this seems to conflict against RCUTILS_COLORIZED_OUTPUT?, which is dedicated env variable for rcutils output message color only. (this is also disabled default, IMO message color can be enabled by default) my suggestion is not to have env variable for this, user can still enable with optinal arguments. if we have to have that, how about ROS2CLI_COLOR_OUTPUT?

Also, if the community decides it's the right time in the future (e.g. when ROS Lyrical becomes the minimum supported distro and Python 3.14's argparse color is on by default), we can revisit and switch the default to on.

yes of course. personally i like the colorized output, and this PR behavior does not have any problem with my environment. but there are some users who do not expect this default behavior change.

[penww]

@fujitatomoya Good point, thanks for the suggestion.

I've renamed it to ROS2CLI_COLOR_OUTPUT to avoid any confusion with RCUTILS_COLORIZED_OUTPUT.
The reason I kept the environment variable is that users who prefer colorized output shouldn't have to specify --color every time.

Would you be comfortable approving this PR? If you have any other suggestions, I'm happy to address them.

[fujitatomoya]

Pulls: #1248
Gist: https://gist.githubusercontent.com/fujitatomoya/1bc7b36d6f81c54b8c291844fa9eb1f8/raw/b1e5de9295a86e3540ce53d99bf673ec5b8973d9/ros2.repos
BUILD args: --packages-above-and-dependencies ros2cli ros2node
TEST args: --packages-above ros2cli ros2node
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/19993

• Linux
• Linux-aarch64
• Linux-rhel
• Windows