Add rich colors to print_msg

[Crivella]

This PR is a proof of concept for adding rich coloring to the console output printed through print_msg

Rich will auto-recognize common patterns (eg dates, file paths) in the printed text and highlight them accordingly

Example:

NOTE:

Would need to adapt test to either not use rich or be aware of the coloring, otherwise most regex check on stdout will fail

[boegel]

Ran 956 tests in 718.139s

FAILED (failures=62, errors=1, skipped=3)

Not sure what the best approach would be to update the tests accordingly...

Maybe force disable Rich by setting some environment variable or configuring with --color=no_color (in EnhancedTestCase.setUp, for example), and then having 1-2 dedicated tests to check output with Rich enabled?

[Crivella]

Yeah i think running all current tests with --color=no_color and add a couple that specifically test coloring would be the easiest

[Crivella]

de4f102 Should avoid breaking stuff when piping the output to a non TTY device

Possibly we might want to even move this to the use_rich() check

[smoors]

@Crivella i tested your PR, but for some reason during the build the coloring is gone after the first line (found valid index for ...), and then comes back at the end (build succeeded for ...). adding --output-style=rich didn't change anything.

any idea what's wrong? is this just me?

[Crivella]

For me it is working throughout all the build.
The code changes are so small that the only thing that would come to mind are:

• something is causing use_rich to evaluate to false in between your build
• something is altering the behavior of rich
• something is causing eb to think that its stdout is non-TTY in between the build

[smoors]

it's indeed the third case: something changes during the build so that sys.stdout.isatty() becomes False.

i managed to fix it by using sys.__stdout__.isatty() instead. would you consider making that change?

[Crivella]

it's indeed the third case: something changes during the build so that sys.stdout.isatty() becomes False.
i managed to fix it by using sys.stdout.isatty() instead. would you consider making that change?

As far as i understand sys.__stdout__ is supposed to be an immutable reference to the original stdout the program was started with, but not what the console is actually printing to.
I think checking if sys.stdout is TTY is the way to go, otherwise you will get colors in a stdout that, at least according to declared properties, should not support them.

Do you know what in your case is causing this behavior? Some hooks overriding stdout or is it something internal to EB that you are triggering while i am not due to configs?

[smoors]

Do you know what in your case is causing this behavior? Some hooks overriding stdout or is it something internal to EB that you are triggering while i am not due to configs?

i don't know what's causing this. i'm not doing anything special, i also disabled the hooks to be sure.

what i did find out is that with with console.capture() (without StringIO) you don't have to specify force_terminal, letting rich autodetect it, and that works for me.

force_terminal (Optional[bool], optional): Enable/disable terminal control codes, or None to auto-detect terminal. Defaults to None.

[Crivella]

what i did find out is that with with console.capture() (without StringIO) you don't have to specify force_terminal, letting rich autodetect it, and that works for me.

Agree we should let the auto-detect do its work seems to work for me as well, gonna commit it and lets see the CI.

[smoors]

suggestion to add some custom coloring

Suggested change

	from rich.console import Console
	console = Console()
	from rich.console import Console
	from rich.theme import Theme
	theme = Theme({
	"success": "bold green",
	"fail": "bold red",
	})
	msg = escape(msg)
	for regex in [r"(\[SUCCESS\])", r"(\[PASS\])", r"( OK)$"]:
	msg = re.sub(regex, r"[success]\1[/success]", msg)
	for regex in [r"(\[FAILED\])", r"(\[FAIL\])"]:
	msg = re.sub(regex, r"[fail]\1[/fail]", msg)
	console = Console(theme=theme)

[Crivella]

I think if we want to add custom highlighting we should probably do so via a custom highlighter

Would not add the extra coloring in this PR.

At that point we could even define multiple themes to be used with the same highlighter for users to choose from (that would work very well in tandem with entrypoints so it becomes very easy to define a custom theme)

[boegel]

I agree, we can revisit this in a subsequent PR.

I think it makes a lot of sense to use the success and fail tags that Rich supports, since I think that still allows for tweaking (through some Rich configuration).