[CHORE] starting base structure for create stack command

[nicolastakashi]

This pull request to the prometheus-operator/poctl project includes significant changes to enhance the command-line interface and improve user interaction. The most important changes include the addition of new dependencies, creation of a new bubbletea package to handle user prompts, the introduction of a handlers package to manage user input, a new log package for better logging, and modifications to the main.go file to incorporate these changes.

New Dependencies:

• module github.com/prometheus-operator/poctl/go.mod: Added several new dependencies such as github.com/charmbracelet/bubbletea, github.com/charmbracelet/lipgloss, and github.com/mritd/bubbles to enhance the command-line interface and improve user interaction.

New Packages:

• internal/bubbletea/question.go: Created a new bubbletea package and defined a Question struct to handle different types of user prompts, including text and selection-based inputs.

• internal/handlers/createStack.go: Introduced a handlers package with a CreateStack function to manage user input and create a new Prometheus-Operator stack based on the user's responses.

• internal/log/log.go: Added a new log package with a NewLogger function to handle logging in different formats.

Main File Modifications:

• main.go: Modified the main file to incorporate the new handlers and log packages. Added a new command "create stack" to the CLI to create a new Prometheus-Operator stack based on user input.

[nicolastakashi]

I don't know why I can't add many reviwers. cc @slashpai @simonpasquier

[nicolastakashi]

It's really hard to grasp the semantics of this bubble project. I wonder if the complexity is worth the pretty UX.

In the design doc you say that you'd prefer to start with a non-interactive mode due to lower complexity, so I wonder what changed your mind here 🤔.

After think about it and I didn't saw other feature which might provide a good value right now besides that, and since it's is the most complete feature, this might be used as foundation to future ones.

Yes, this is quite complex library and the doc is not that good. Besides this one I also checked https://github.com/rivo/tview/?tab=readme-ov-file which is used by k9

[ArthurSens]

Not sure if I've done something wrong, but I get panics when trying the CLI

[ArthurSens]

I don't see monitoringv1 being imported anywhere, I'm very confused what the create stack command is supposed to be doing 🤔

[ArthurSens]

AAAH OK, I think I finally understood! It's not supposed to do anything, as you mentioned in the PR title it is just a base structure so later on you can implement the real thing.

Ok ok, I appreciate the effort you've made so far... the code looks complex so I'm pretty sure you put some hours into understanding everything. I'd like to suggest a different approach though, if we introduce complexity before we add value, this is going to be super hard to evolve. It's not only you who spend hours understanding and implementing the PR, but Simon, JP, and I will also spend quite some time understanding everything before we are confident enough to approve it. Not to mention that once we start to implement the real thing we might notice that we took the wrong direction and we will need to refactor everything.

As you mentioned in your design document, the interactive mode is the last step to be implemented. A non-interactive mode is easy to implement and we can start using it right now! I've lost count of how many times I had to clone kube-prometheus because I wanted to test a PR in prometheus-operator that required me to run a stack alongside the operator.

[nicolastakashi]

I'm ok with starting with non-interactive mode, don't think we will have a way to move away from the complexity of understanding this lib or any other lib structure about TUI applications.

I already have other branching where I started to create prometheus operator objects, but my feeling is we will just move the review of something similar to this to the future 😅

[ArthurSens]

my feeling is we will just move the review of something similar to this to the future 😅

Totally understandable and I agree with you :)

But starting simple allow us to release something usable faster and we can finally make this repo public. With a bigger community I believe we will get more feedback and more reviewers for the complex parts

[nicolastakashi]

@ArthurSens I'll remove charm dependencies for now and I'll only let the flags and logger setup, just to not recreate everything in another PR.