> If you have downstream operations frequently parsing unstructured CLI output > using sed or awk and the output has no defined contract (ideally openAPI) > then this seems backwards to me and is going to be a constant source of > breakage for users and friction when evolving our product. Strong +1 to this sentiment. Having an OpenAPI description and having a default implementation that outputs to .json for instance would help decouple us from the current state of viewing our text-based CLI output as being an implicit API. Which is just not great for anyone.
Also - I for one love me some colored output. We do it with our IDE's for a reason; why not with our CLI tools or logs? ;) On Sat, Jul 20, 2024, at 3:26 PM, Miles Garnsey wrote: > I don’t usually chime in but I’m a +1 on PicoCLI. I think it’s a great > project and the autocompletion features are a game changer for people like me > who prefer the CLI and use many CLI tools infrequently. The coloured output > is… nice, I guess. > > Whatever the decision, I think at a strategic level the project should > consider a more principled approach to CLI output. If you have downstream > operations frequently parsing unstructured CLI output using sed or awk and > the output has no defined contract (ideally openAPI) then this seems > backwards to me and is going to be a constant source of breakage for users > and friction when evolving our product. > > I don’t deny that a change of that magnitude may be a big lift, but to the > extent that we’re concerned about moving off a deprecated library based on > the fact that we have what amounts to an undocumented, uncontracted, and > unversioned API, this seems poor practice bluntly. > >> On 21 Jul 2024, at 1:44 am, Dinesh Joshi <djo...@apache.org> wrote: >> >> On Tue, Jul 16, 2024 at 8:48 AM Jeff Jirsa <jji...@gmail.com> wrote: >>> if it’s unmaintained, let’s remove it before we’re doing it on fire. >> >> +1 >> >> Fire drills are never pleasant. >> >> CLI parsing isn't a huge area of personal interest to me. However, it >> presents a non-trivial attack surface as input processing is a ripe target >> for vulnerabilities. I don't know if there are vulnerabilities lying around >> in hiding but if / when they are reported we will need to address them >> outside of the library or migrate to a maintained library at that time. >> Neither option is very appealing at that point. So I am of the opinion we >> should transition to a maintained library with healthy community support. >> Both picocli and commons-cli have good adoption and community around them.
