Formatting mini-language for 0.10

[henryiii]

Currently, we are exposing our Rich-like mini-language. It hasn't been public until message.* options were added, so the question arises: should we keep it, or replace it with a color object? The message expressions already have {} formatting support, so we could use {color.red}{color.bold} instead of [red bold].

Benefits of the mini-language: mimics Rich, can possibly merge several options into one escape sequence (though I don't think we do that now, and pretty minor), and might be able to be smart about resetting (though we could post-process the string and apply resets in the other form).

Benefits of the formatting object: only requires .format pass, doesn't need us to process [], [] no longer has special meaning, [new-color] won't change meaning if we add "new-color" later. I'm also not sure if we handle escapes yet, but we wouldn't have to worry about it with a formatting object.

[LecrisUT]

What format is generated if we use CMAKE_COLOR_DIAGNOSTICS=ON (i.e. ninja, gcc and clang primarily) and how does/will scikit-build-core translate the color from the CMake logs to forward to pip or the logger in general?

[henryiii]

We don't touch the output from CMake, it's just directly exposed without buffering, etc, this is just for the various rich_print() calls, which is now exposed publicly as tool.scikit-build.message.after-failure and tool.scikit-build.after-success.

[LecrisUT]

What I had in mind is if it is possible to make the tagging equivalent so that the result of e.g. {color.red} would be colored in both scikit-build.message but also in the pip -v. If the backends use ANSI codes directly, it might be quite difficult though.

[henryiii]

For now, you'll still need FORCE_COLOR for pip. We can't detect if we are being redirected to a file since pip is buffering the output so that it can indent it and such. I'm not a fan at all, but that's pip's issue.

This is just about "[red bold]This is an error" vs. "{color.red}{color.bold}This is an error".