Closed tbauriedel closed 3 weeks ago
A simple TUI that guides through the execution should be doable. I do think it's still beneficial to have a config or answer file, that can that be fed by a TUI. That way you can use both and implement them independently.
Having application specifics (--icinga...
, --elastic...
) in the CLI is an anti pattern imho. But I don't work with the tool, so it's just my opinion.
I have some ideas how we could update the argument handling using an 'interactive wizard'.
As already mentioned several times, the tool is kept as simple as possible so that even "non-technical" users can use the tool as required. A forced config file would therefore not only break the principle of "just run it and it collects what it can", but would also make it unnecessarily complicated to use.
But with the idea of automatisms and similar, a wizard for argument handling is counterproductive. So the best thing will probably really be to find a combination. A wizard with explanations, etc. by default. In addition, a possibility to configure the whole thing via config file.
I have started with a small prototype and tests for the wizard here. (Attention: The whole thing is far from ready for production)
Describe the feature request
We have a lot of possible arguments u can use at the moment.
For a better usage we should discuss if we should an something interactive or input per config file.
I don't currently see arguments in conf files as very useful. The support collector is built in such a way that even a non-technical user can use it as easily as possible. Therefore, I would currently rather go in the direction of an interactive wizard, or something.
Opinions welcome @martialblog