ANSI escape sequences

[cachitas]

I am facing an issue using rich.logging.RichHandler with Django and werkzeug.

The details were covered in the werkzeug repository, see pallets/werkzeug#2340.

In a way I agree with @davidism, but I would like to know what you guys here think about it.
Is there a way of tackling this with rich that I am missing?
Could rich automatically detect these ANSI sequences? Is this something worth pursuing?

[davidism]

You can always attach a normal stream handler to the werkzeug logger namespace, so that the rich handler on the root doesn't mess with the dev server output.

[willmcgugan]

Hi @davidism I'm surprised Wekzeug writes ansi codes in to logs. How do you ensure that ansi codes aren't generated for logging handlers that don't write to the terminal?

[davidism]

I don't, because I don't expect the Werkzeug dev server to be used in such a situation. The only thing I do is disable color output on Windows if colorama isn't installed.

[cachitas]

Just to be clear, I am experiencing all this in a development environment.
The main issue I think is just the interoperability of werkzeug and rich in two aspects: ANSI codes and the timestamp inside square brackets without the possibility of escaping.

@davidism Following the Windows case, would it be possible to implement a flag to control the styling? I see you already have a _log_add_style you use internally.

Then one could also look if rich is available like you do with colorama. Maybe we need to check if the current handler is a RichHandler. You already do something similar when assigning a custom handler if none is set.

[willmcgugan]

@cachitas It's not common practice to have ansi codes in log statements. I don't think that the Werkzeug devs anticipated anyone would want to configure their dev server with a different terminal logger.

If you really can't live without the RichHandler you could extend it to process ansi codes with the rich.ansi.AnsiDecoder class. Or exclude that output from the RichHandler as @davidism suggested.

[cachitas]

If you really can't live without the RichHandler

This is on you for putting together such a cool library :)

For now I am excluding werkzeug from my logging configuration as suggested. The downside of having log messages using different handlers/formatters is the visual inconsistency of the output in development. I still need to give it a try in a production environment but, since werkzeug is out of the picture, one should expect no issues.

I still need to explore that AnsiDecoder path. Will get back to you on this later.

[cachitas]

After digging a bit more on this, I found that werkzeug is not as guilty of this situation as I initially thought. Apologies!

Turns out django-extensions runserver_plus does some magic of its own. See set_werkzeug_log_color.

Here they patch werkzeug log method and apply the styling using django style utilities which are the true responsible for injecting the ANSI codes, following werkzeug example. They also follow the same message format with the timestamp inside the square brackets.

So in the end, for people using runserver_plus, this is where rich support would have to be handled I think.

I would like to welcome @trbs to join the discussion or point someone else from the project who could shed some light on the matter.