Consideration to put num_ansi_colors in an independent upstream package

[MichaelChirico]

num_ansi_colors() really is a wonderful piece of logic. I think other packages working with command-line interfaces would benefit from it without needing to depend on {cli}.

This came up as a suggestion here:

markvanderloo/tinytest#90

WDYT, is that worthwhile to pursue?

[gaborcsardi]

This would indeed make sense in an ideal situation, but when it comes to (R) packaging in practice, the situation is not exactly ideal.

I guess the question is mostly academic for the tinytest package, I cannot imagine that they would add a new dependency, however small.

In any case, the crayon package is pretty close to what that new package would be. crayon copies the same logic as cli, and it is pretty small and lightweight, has no C code. It is superseded, so it'll never really change (except for num_ansi_colors() updates!), and will stay around forever.

[MichaelChirico]

I guess the question is mostly academic for the tinytest package, I cannot imagine that they would add a new dependency, however small.

I suspect you may be right, but it does seem easy enough to put this under Suggests, which is more likely to go forward.

{crayon} is a great suggestion and glad to know the num_ansi_colors() part will continue to stay in sync with {cli}. {crayon} does come with a lot of other stuff above&beyond the simple color detection logic, but as you noted it's very small (~40k) so I think it's moot.

when it comes to (R) packaging in practice, the situation is not exactly ideal.

I wonder if you would mind expounding on that for my own edification, not sure I see exactly what you have in mind. Optional & thank you in advance for your time & input. Closing since the request here is already satisfied.