chore: Improve Tool's Output for Better User Visibility and unify CLI output library

[camilamacedo86]

Description

Ensuring that users can swiftly identify critical warnings and errors is important for a smooth user experience. This PR focuses on making these critical messages stand out amidst the standard output of our tool. Specifically, the changes introduced are:

• Unify CLI Output Library: To provide a consistent output experience across all messages. (see that has places we are using fmt.Println others logrus which are not in debug mode and by last other, we are using the colour.faith )
• Color-coded Messages:
  • Errors are now highlighted in red, making them immediately noticeable.
  • Warnings are displayed in yellow, ensuring they are distinguishable from regular logs and errors.

Example:

[doanac]

I think using a logger for a CLI user interface is a little unusual. I believe the more common approach is abstracting code that prints stuff into some type of project "formatter" where the Print type function gets some context to help know about coloring.

[camilamacedo86]

Hey @doanac! 😊

I think using a logger for a CLI user interface is a little unusual. I believe the more common approach is abstracting code that prints stuff into some type of project "formatter" where the Print type function gets some context to help know about coloring.

Ah, you got a point! We've got logrus in the mix already, so I figured, why not stick to the beat?

But hey, I’m totally vibing with the fmt.Print idea. It’s neat and cuts down on the extra baggage – cool beans! I’ll spin that record and make the tweaks when I catch a free moment.

Thanks a bunch! 🚀

[camilamacedo86]

Hi @vkhoroz, @doanac,

Firstly, thank you for your valuable insights regarding this small suggestion.

Regarding the use of println with ANSI colors:

Using fmt.Println("\033[31mERROR:", "Your message", "\033[0m") might not deliver as expected. In terminals that don't support ANSI sequences (which seem prevalent in older Unix and Windows versions), the output won't display colors and will instead appear as \033[31mERROR message\033[0m.

On the other hand, logrus appears to be adept at navigating these scenarios, opting to simply output ERRO in incompatible terminals.

The driving force behind this proposal was to enact a low-effort/good first issue that could provide tangible value to our users. With the volume of notifications we produce, errors and warnings could easily go unnoticed. Given our ongoing use of logrus, it felt like a logical step to further embed it, ensuring greater code consistency.

However, if logrus doesn't align with the team's vision, especially when weighing the challenges associated with fmt.Println and ANSI, it seems wise to reassess this one.

For now, I'll be closing this. However, if you have alternative strategies in mind or believe there's a more effective approach worth exploring, please don't hesitate to reach out. I'm always here to assist and collaborate

[camilamacedo86]

Hi @doanac and @vkhoroz :

I've revisited this issue and observed that we're also utilizing the "github.com/fatih/color" package in certain areas. Given that we're already leveraging this package elsewhere, can we consider employing it for displaying errors in red and warnings in yellow? It would be beneficial to maintain consistent behavior across the tool. What are your thoughts on this?

See:

fioctl/subcommands/keys/tuf_updates_review.go

Lines 93 to 97 in 0ac0f5f

	color.Green(line)
	} else if line[0] == '-' {
	color.Red(line)
	} else {
	fmt.Println(line)

[vkhoroz]

@camilamacedo86 let's table this, please.

I know that this change was done by some sort of find magic -exec sed magic, so it was probably easy.
But, TBH I don't like the final result.

If I were a user, I'd like only the ERROR part to be in red, and the message itself not so fancy.
This also means, that as a developer I'd want all these messages to be refactored to use subcommands.DieNotNil where applicable.

But, I feel like I'm starting a discussion by this sentence; and I don't want a new round of debates.
We have more important tasks to spend our effort.