Re: [DISCUSS] Replace airlift/airline library with Picocli

[Josh McKenzie]

> if someone proposed adding this library right now, we’d all say no because 
> it’s unmaintained.
Interesting. This perspective resonates with me, but it also raises the 
immediate next thought of "we should make it a point to proactively move off 
unmaintained dependencies or take them in-tree". In terms of general project 
health this seems like a healthy posture for us to take.

Would the blast radius of that thought exercise extend far beyond the CLI 
parsing case here, or is it pretty isolated?

I'm sympathetic to the "it's small, it's stable, it's a well solved problem, 
don't fix what isn't broken" argument, as well as the fiddly edge-case breakage 
that can occur in terms of output formatting and stderr vs. stdout etc. That 
said, for me all the implications surrounding the argument of "don't depend on 
something external that's dead" marginally outweigh that.

On Wed, Jul 17, 2024, at 10:04 AM, Tibor Répási wrote:
> 
> 
>> On 17. Jul 2024, at 01:28, David Capwell  wrote:
>> 
>> We also must weigh the risk of stability… Changing something for the sake of 
>> changing it may get past all our CI then could break a user as they used 
>> something we were not aware was being done (return codes, stdout/stderr, 
>> etc.); replacing something public facing comes with massive risk.
>> 
> 
> That’s completely true, which augments the importance of proper tests. 
> Currently, many tests lack coverage to this, which in my opinion is an issue 
> that needs to be addressed in the migration work. The outcome should be to 
> have lots of tests more and higher coverage than we have today.
> 
>> 
>> Again, must weigh the risk vs the reward.  Sure, we could have colored 
>> output, but if that breaks users was it worth it?
>> 
> 
> Colored output might be very useful and nice, but honestly, it won’t justify 
> that risk. Let me try to put some more weight to the reward pan of the scale:
> 
> - shell command autocompletion: the current completion script is limited to 
> nodetool only, is barely up to date with the CLI and pretty clumsy and 
> tedious to maintain. PicoCLI can auto-generate the completion script enabling 
> to be part of the release process which will assure to have an always up to 
> date completion script shipped within the distribution packages without 
> additional maintenance efforts.
> 
> - man pages (feel free to call me old): Cassandra completely lacks of 
> distributing man pages now, but do not underestimate the power of them. 
> Documentation depends on version, and probably the easiest way to get proper 
> documentation that aligns with the currently installed version is to type 
> man. While the help subcommand might give you a short summary on usage, the 
> man page can provide deeper insight of what it does, explanation of arguments 
> and options, examples, return codes, etc. PicoCLI anticipates man page 
> content and allows to generate man pages, e.g. during the release process to 
> be distributed along with the software. Autogenerated man pages could also be 
> used to update the documentation on the website. All this information would 
> be single sourced from at the actual implementation.
> 
> Though, these improvements won’t come out of the box, but PicoCLI allow us to 
> go for it, while airline won’t.
> 
> 
>> On 16. Jul 2024, at 18:01, Caleb Rackliffe  wrote:
>> 
>> With concerns around licensing all but resolved, I'd support Pico as our 
>> airline replacement. It looks like it would entail the least risky 
>> migration, is being actively maintained, will make the development of a 
>> number of planned enhancements easier, etc.
> 
> Are these licensing/legal concerns bigger than those about stay on airline?
> 
>> On 16. Jul 2024, at 17:39, Jeff Jirsa  wrote:
>> 
>> (Answering this as a cassandra person, don’t confuse this reply as 
>> board/foundation guidance)
>> 
>> The legal landscape is rapidly evolving with the CRA. The answer may change 
>> in the future, but I think “we have a dependency we ship that’s 
>> user-accessible and known to be abandoned” is an unhappy state that’s 
>> indefensible if there’s ever a transitive dependency issue (e.g. log4j style 
>> “oh who would have guessed that was possible” ). 
>> 
>> I’d look at this slightly differently - if someone proposed adding this 
>> library right now, we’d all say no because it’s unmaintained. That alone 
>> should be enough justification to fix the obvious problem - if it’s 
>> unmaintained, let’s remove it before we’re doing it on fire.
> 
> I really like this PoV and the size of the work is big enough to not want it 
> to be done in an emergency. What I’d like to augment here is, someday PicoCLI 
> might be obsolete as well and the CLI would need to be migrated to the next 
> library. Maxim already tried to separate things as good as possible to limit 
> the impact of such a change in the future, however, we should have an eye on 
> that aspect too.
> 
>> On 16. Jul 2024, at 14:49, Aleksey Yeshchenko  wrote:

Re: [DISCUSS] Replace airlift/airline library with Picocli

[Dinesh Joshi]

On Tue, Jul 16, 2024 at 8:48 AM Jeff Jirsa  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.

Re: [DISCUSS] Replace airlift/airline library with Picocli

[Miles Garnsey]

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  wrote:
> 
> On Tue, Jul 16, 2024 at 8:48 AM Jeff Jirsa  > 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.