support logging setups with multiple handlers, by taking a rich-markup(ed) msg from an extra-field

[calestyo]

Hey.

With rich.logging.RichHandler there's the markup= parameter which defaults however for good reason to False.
Also one can use extra={"markup": True} in an actual log message (like via logging.error(...)).

While this allows fine control over specifically sending a log message with rich’s markup it still has, AFAICS, one problem.

The msg parameter of the logging call will now contain the markup and that may also be picked up by any other handlers.
Often these handlers are configurable by the user via some config file.

What one wants however, is that only RichHandler gets the markup version and all others the non-markup version.

Basically I see to ways to get this:

1. rich could provide it’s own derived version of Logger where it overrides the logic and strips the markup for any except its own handler.
   The downside of this is that people would have to use the derived Logger, which brings all kinds of issues (e.g. people might want to make rich an optional dependency).
2. Add a rich_markup_msg as an extra field, which only RichHandler would pick up and, if given, use instead of msg (it could of course also do the string interpolation using the *args, just on rich_markup_msg=.
   People would the need to call like:
   logger.error("This is a SERIOUS error code %s!", error_code, extra={"rich_markup_msg": "This is a [bold red blink]serious[/] error code %s!"}
   Now while the doubling of the message is ugly on the one hand, it’s also a chance on the other, since one might want to use a different string in case rich isn’t used, like above where I wrote the SERIOUS that would be used by non-RichHandler-handlers in capital letters.

Cheers,
Chris.

PS: I’d suggest to prefix the extra field with rich_ so that other handlers are less likely to pick it up by accident. The same should IMO have been done with markup which is a pretty generic term.

[calestyo]

Thinking about it, it may actually be a bit more difficult. People might also want to use markdown in the *args that are to be interpolated into the msg ... but these would again end up at all handlers... not just the one from rich.