(Exploratory) Evaluating bubbletea as a Replacement for logrus

[camilamacedo86]

What do you want to happen?

This is an exploratory task aimed at improving UX. In Kubebuilder, we might want to replace logrus with bubbletea.

Note that if we merge, a PR should replace logrus entirely and include changes to the create API command, where we will ask the user if they want to make a controller and API using bubble tea's interactive features:

See

$ kubebuilder init
INFO Writing kustomize manifests for you to edit... 
INFO Writing scaffold for you to edit...          
INFO Get controller runtime:
$ go get sigs.k8s.io/controller-runtime@v0.20.0 
INFO Update dependencies:
$ go mod tidy           
Next: define a resource with:
$ kubebuilder create API


$ kubebuilder create api
INFO Create Resource [y/n]                        
y
INFO Create Controller [y/n]                      
y

To evaluate we would need to see at least those steps with the lib to check if we are in the right direction. This is an exploratory task to determine how we can improve our users' UX. This change aims to evaluate and explore the feasibility and benefits of using bubble tea in bubble tea in Kubebuilder.

However, if the PR meets the acceptance criteria and is considered good (we decided that is a good approach to move forward), then this needs to ensure that moving to place the l is completed.

Tasks:

• Replace logrus:
• Remove all instances of logrus in the codebase.
• Implement bubbletea for logging and interactive user prompts. Example: Update create API Command:
  • Use bubbletea to prompt users interactively about creating a controller and API during command execution.

Extra Labels

No response

[damsien]

Few questions:
Did bubbletea exist when the kubebuilder project was created?

If so, why did we chose logrus instead of bubbletea? Are there any old discussions about this?

[camilamacedo86]

The kubebuilder was created on Mar 15, 2018.
So, I am not sure when this lib was created.

why did we chose logrus instead of bubbletea?

Kubebuilder has a policy of avoiding unnecessary dependencies (as much as possible). Initially, we used fmt for logging and displaying information. Later, we adopted logrus because it was widely used, simple to implement, and offered a better user experience. So, we must evaluate this one well before deciding to adopt and move forward.

Now, there is an opportunity to explore another library that is also well-regarded and may provide an even better user experience. In my opinion (IMHO), it’s worth investigating this option. To make an informed decision, we propose conducting a proof of concept (POC via a PR). Additionally, we should bring this discussion to gather feedback and identify any concerns or reasons against this approach. This is the goal of this task.

It’s important to note that this issue only intends to explore the feasibility of adopting this new library. We are not committed to making this change. Before proceeding further, a thorough evaluation of the pros and cons will be necessary.

I was (personally) interested in evaluated, but if others want to give a look and let us know their learning, that would be great.

[migueleliasweb]

Hi Camila, thanks for always improving Kubebuilder.

Out of curiosity, was slog ever considered?

It's "builtin" whilst providing a more modern interface for loggers.

https://go.dev/blog/slog

[camilamacedo86]

Hi @migueleliasweb,

Is this the GitHub repository you were referring to? https://github.com/gookit/slog
If so, considering it has less than 500 stars, it seems like it hasn't been widely adopted. This raises concerns about its long-term maintenance and support.

Additionally, unless I misunderstood, it appears to be more focused on logging for the manager/controller itself, which originates from the controller-runtime.

For our case, this exploration is more about improving the CLI UX—making the experience better and more user-friendly for CLI users. It doesn't seem related to the scaffolding work being done.

[migueleliasweb]

Oh, now I see.

The mention to Logrus was a hook for me to think this was more to do about logging other than about a whole TUI investigation.

Slog can be found here: https://pkg.go.dev/log/slog

But yeah, they're very different packages.

[camilamacedo86]

See that the logs generated in the controllers are coming from controller-runtime: controller-runtime example in kubebuilder.

Kubebuilder itself is built on top of controller-runtime, and it aims to provide scaffolds that address common and essential needs without including third-party dependencies. Adding third-party libraries to the scaffolds is something we generally want to avoid. While there are a few exceptions, those were carefully considered, widely adopted, and align with established best practices. (cert-manager and golang-ci to lint the code)

Our primary goal is to minimize reliance on third-party dependencies in the default scaffolds. However, end users are always free to modify the default scaffold to accommodate their own specific needs and preferences.