highlight warnings and errors #278
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds colored output formatting to warning, error, and critical log messages in the console handler, making them easier to identify at a glance. The changes enhance the logging system by prepending level names to warnings and above, and applying ANSI color codes for visual distinction.
- Introduces a
ColoredFormatterclass to apply colors to log messages based on severity - Configures the console handler to use the new colored formatter
- Adds visual differentiation for WARNING (yellow), ERROR (red), and CRITICAL (red background) messages
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| class ColoredFormatter(logging.Formatter): | ||
| # ANSI escape codes (CSI Control Sequence Introducer) | ||
| COLORS = { | ||
| logging.WARNING: "\033[1;33m", | ||
| logging.ERROR: "\033[1;31m", | ||
| logging.CRITICAL: "\033[1;41m", | ||
| } | ||
| RESET = "\033[0m" |
There was a problem hiding this comment.
The ColoredFormatter class applies ANSI color codes unconditionally, which may cause issues in non-TTY environments (e.g., CI/CD pipelines, log files viewed in plain text editors). Consider checking if the output stream is a TTY using sys.stdout.isatty() before applying colors, or provide a way to disable colored output.
There was a problem hiding this comment.
It should not be a problem afaict, since I've already seen colors in CI/CD logs (and ANSI escape codes in raw log output)
There was a problem hiding this comment.
For a simple tool like this, I don't think we need to worry about toggling color output, because doing it properly requires a combination of detecting TTY, inspecting the environment (https://no-color.org/) and supporting explicit --color and --no-color flags, and determining the precedence of each method.
2 participants
Follow up of eth-cscs/alps-uenv#276 (comment), covering just the "colored" part for highlighting messages.