Re: kci command line poll: Click or Typer?

[Guillaume Tucker <guillaume.tucker@collabora.com>]

On 21/09/2023 10:59, Guillaume Tucker wrote:
> Alongside the new KernelCI API we're also working on the new
> command-line tool "kci".  One of the key decisions to make is the
> framework to use for its implementation.  The legacy KernelCI
> tools use the standard argparse, now we may consider using Click
> or Typer as they are popular Python alternatives.
> 
> Here's a small poll with extra context to help people make up
> their mind and vote for their favourite choice:
> 
>   https://github.com/kernelci/kernelci-project/discussions/258
> 
> If you don't have a GitHub account, you can also reply to this
> email to vote instead.  Feel free to also bring up any discussion
> topics here or with GitHub comments of course.
> 
> We'll look at the results at the end of the month so there's a
> bit more than a week left to answer the poll.

The results are in, basically all 3 options received the same
number of votes!  However, there have been very constructive
discussions around it and a fair amount of engagement from the
community which is very encouraging.

Here's a summary with collected pros/cons for each option:

  https://github.com/kernelci/kernelci-project/discussions/258#discussioncomment-7172705

an a proposal going forward:

  https://github.com/kernelci/kernelci-project/discussions/258#discussioncomment-7172800

I'm including a copy of the proposal from the GitHub comment here
for the benefit of the mailing list:

> What I would propose is to start with Click using the version
> currently in Debian Stable (v8.1.3) as it has so many
> advantages over argparse.  Then if users find the Click
> dependencies too cumbersome, we may consider bundling it
> directly with the kernelci package, probably with a Git
> submodule or directly added to the repository under
> kernelci.click.
>
> As a fallback, if we later find that adopting Click in the
> community still requires a larger effort than maintaining an
> implementation based on argparse we might be able to convert
> the tool to argparse then.  This scenario seems very unlikely
> as there aren't any actual signs that Click is more difficult
> to adopt than the existing dependencies (see requirements.txt
> in kernelci-core repository).  So the risk seems very low, and
> if we did hit this kind of problem we would still have a way to
> mitigate it.

Like many important technical decision, it's a compromise between
diverging requirements.  Please raise any concerns you may have
now if anyone believes there are going to be blockers with using
Click as the kci command line framework.  We need to have a
stable implementation by the end of November to meet the next
KernelCI API milestone, as such the implementation of the new kci
tool will probably start next week.  Also, please let us know if
you want to contribute ;)

Thanks,
Guillaume


PS: We should bundle CloudEvents with the kernelci package...