cli: colorize build statuses

[FrostyX]

The python-rich package is available for EPEL9+ so for EPEL8 we would need to do some workaround.

[gemini-code-assist]

Code Review

This pull request introduces colored output for build statuses using the rich library, which improves the user experience of the CLI. The implementation is mostly correct, adding a new --color/--no-color flag to control this feature. However, there's a critical compatibility issue with the argparse action used, as it's only available in Python 3.9+ while the project seems to support older versions like Python 3.6 on EPEL 8. I've also included a suggestion to improve code style and performance in the new helper function.

[gemini-code-assist]

The argparse.BooleanOptionalAction was introduced in Python 3.9. Since this project supports older Python versions (e.g., on EPEL8 which has Python 3.6), using this action will cause the program to fail on those systems. To maintain compatibility, you should use separate actions for enabling and disabling the color feature.

    parser.add_argument('--color', dest='color', action='store_true', help="Enable colorized output (default).")
    parser.add_argument('--no-color', dest='color', action='store_false', help="Disable colorized output.")
    parser.set_defaults(color=True)

[FrostyX]

I was bored on a weekend and wanted to try the rich package. If you don't like this, we can drop it, no problem :-)

It looks really cool though.

[github-actions]

Pull Request validation

Failed

🔴 Failed or pending checks:

• RPM package copr-cli[failure]

🔴 Review - Missing review from a member (2 required)

[praiskup]

for EPEL8 we would need to do some workaround.

Or we can package it.

[praiskup]

Terminal colors are normally on by default, the frameworks detect incompatible terminals and automatically turn colors off... if something screws up, there should be --no-color.

[FrostyX]

This argparse.BooleanOptionalAction implements both --color and --no-color :-)

[FrostyX]

But as Gemini pointed out, this is available only since EPEL9+ so we will probably need to do a mutually exclusive group or something.

[praiskup]

Hm, do we need the --color option?

[praiskup]

It's pity to keep canceled as "default".
Eventually, explicit "default" value doesn't make sense (it's returned if key is not found in dict).

[FrostyX]

I wanted to use the same colors that we have on the website

[praiskup]

colors are up to you, but those fields setting "default" to "default" are redundant, right?

[FrostyX]

but those fields setting "default" to "default" are redundant, right?

Correct, they are. I just wanted to enumerate the all of them to for easier searching and future changes. And I also wanted to be more explicit what their color is. But yea, they would be picked by the .get(..., "default") otherwise.

[FrostyX]

for EPEL8 we would need to do some workaround.

Or we can package it.

Good call, it wasn't that hard
https://src.fedoraproject.org/rpms/python-rich/pull-request/16

[FrostyX]

The CI is still failing because the python3-rich for EPEL8 is still in testing but it should start working once it gets to stable. I tested locally in container and the feature works well on EPEL8.