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 > <mailto: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.
