RE: [Automated-testing] kci command line poll: Click or Typer?

> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of Guillaume Tucker via
> 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.

Ok - sorry about this, but here goes...
<rant on>

I see exactly 0% of the people saying to stay with argparse, but that would be my recommendation.
The rationale for this is that argparse is old and unlikely to be changed in an incompatible way in
some future version of Python. 

My own rather unfortunate experience with Python is that it used to be a reliable, stable, robust
language with backwards compatibility, but that is no longer the case.   Python keeps altering modules
in incompatible ways, introducing new syntax that is not compatible with previous versions of the language,
and deprecating modules that are in wide use.  Just this past year, the powers-that-be
in Python decided to deprecate the 'cgi' module, and remove it from the core python libraries. I have several
(admittedly, very old) python-based cgi scripts that use this module.  I'll likely have to rework these scripts
in the future, just to keep them from breaking, as newer versions of Python are distributed with Ubuntu and Debian.
A similar thing has happened with other modules, such as urlparse and openpyxl.  Both of these modules
were refactored by their authors in a non-backwards-compatible way, which caused breakage and requiring
refactoring of my own python programs.  I can attest that keeping python programs running unmodified
for longer than 10 years is a real chore.  The same is not true of Linux programs and C libraries, where
backwards compatibility has been a priority for the upstream developers.

The fact that there are now additional argument-parsing options available
for Python, that one needs to choose between, kind of underscores my point.  Which one will Python stick with?
Will python drop support for argparse, chasing some new "module-of-the-month" for argument parsing?
The future of long-term support by the Python community for any of argparse, Click or Typer is, IMHO, very
much in doubt.

If you do stay with argparse, I would pull a current copy of the module into your own repository, so
you are not dependent on updates or external repositories.

For my own projects, I have my own argument parsing functions written in native python, so I am reliant
on as few core python modules as possible. (So my answer, for my own projects, to the question of which
external python  module to use for argument parsing is "none of the above".)
The python community just cannot be trusted not to break the language or the core modules in a
backwards-incompatible way.

If the python community cared about backwards (and forwards) compatibility, they would not need
the whole mess that is virtual environments.
<rant off>

Just my 2 cents.
   -- Tim