Closed cmorigaki closed 1 year ago
Thanks for the feedback!
The string implementations were all in CliktCommand
since, prior to 4.0, there were multiple implementations of Option
and Argument
. Now that there's only one of each, implementing toString
in them makes sense.
I'm not sure about adding lifecycle callbacks. Since it's only a couple of lines of code to do yourself, I'd need to see more use cases before I add a feature like that.
Awesome! Thanks!
Hi, I'm adding analytics to the CLI and one of the use cases is sending an event of the invoked command with its arguments/options. To avoid repetition and ensure every command sends the event, my current implementation looks like this:
Two Clikt modifications would improve my code and I believe it would also improve Clikt code:
Add observer for child command run. That way instead of creating a Base class, the parent command could observe and send the event after the parsing phase. Also, I would get rid of the
final
andonRun()
workaround because there is no way to force the super method call and ensure the event is sent.Implement
OptionWithValuesImpl.toString()
andProcessedArgumentImpl.toString()
. To collect options and arguments information, I replicated part of theClickCommand.toString()
. Implementing these overrides, would also simplifyClickCommand.toString()
.I checked the code and the first one seems not trivial. For the second, not sure if I'm missing something else here but I would like to contribute with a PR.