> 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 <dcapw...@apple.com> 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 <calebrackli...@gmail.com> 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 <jji...@gmail.com> 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 <alek...@apple.com> wrote: >> >> Are there outstanding bugs in airline though, and any that affect Cassandra >> specifically? >> >> There is software that requires ongoing maintenance and these is software >> that really doesn’t. These are simple libraries, doing one isolated thing, >> that don’t need to change once they work - they are *done*. > No, there are no outstanding bugs for now and as airline is known to be > deprecated newly uncovered bugs probably won’t be tracked or fixed, too. This > state is also prone to fail on some changes in the environment, e.g. Java, > which would then render the CLI dysfunctional. All these might not highly > probable but the effort for addressing them is growing. As also mentioned > above, maintenance is better done before everything is burning. > >> On 15. Jul 2024, at 20:53, Maxim Muzafarov <mmu...@apache.org> wrote: >> >> The question is: >> Does everyone agree with using Picocli as an airlift/airline >> replacement for our cli tools? > Yes, I am. +1 >
