kci command line poll: Click or Typer?

kci command line poll: Click or Typer?

[Guillaume Tucker]

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.

Thanks,
Guillaume

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

[Bird, Tim]

> -----Original Message-----
> From: automated-testing@lists.yoctoproject.org <automated-testing@lists.yoctoproject.org> 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

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

[Richard Purdie]

Hi Tim,

On Thu, 2023-09-21 at 19:41 +0000, Tim Bird wrote:
> 
> 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.

I saw this and found it interesting. I've somehow ended up working with
and maintaining a relatively complex python application for over 15
years (Bitbake in case it isn't obvious). Admittedly we've tried to
keep it's dependencies minimal (much to the frustration of some) so
I've not had much exposure to the wider module ecosystem and I've point
blank refused to 'need' virtual environments for our use.

Whilst there certainly have been annoyances and the 2->3 migration had
its moments, in general I've not found it to be that bad. I started out
wanting to use something else but over time have grown to quite like
the language and I'm not sure what we do would have worked in something
else. Where there have been changes, you can see there were clear
improvements they were trying to make.

Most of the feedback I get is that we should be embracing modules and
I'm stuck in the past keeping things minimal but it clearly does have
some advantages! I've forever being pushed to require a higher minimum
python version so we can adopt new language features.

Just a different perspective :)

(we use argparse FWIW)

Cheers,

Richard

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

On Thu, Sep 21, 2023 at 09:17:02PM +0100, Richard Purdie wrote:
> On Thu, 2023-09-21 at 19:41 +0000, Tim Bird wrote:

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

> years (Bitbake in case it isn't obvious). Admittedly we've tried to
> keep it's dependencies minimal (much to the frustration of some) so
> I've not had much exposure to the wider module ecosystem and I've point
> blank refused to 'need' virtual environments for our use.

FWIW assuming the issues Tim has run into are similar those I'm aware of
then modulo the general stuff with the 2->3 transition (which was it's
own special thing) the issues are all in the module ecosystem rather
than the core language and standard library.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Bird, Tim]

> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> On Thu, Sep 21, 2023 at 09:17:02PM +0100, Richard Purdie wrote:
> > On Thu, 2023-09-21 at 19:41 +0000, Tim Bird wrote:
> 
> > > If the python community cared about backwards (and forwards)
> > > compatibility, they would not need
> > > the whole mess that is virtual environments.
> 
> > years (Bitbake in case it isn't obvious). Admittedly we've tried to
> > keep it's dependencies minimal (much to the frustration of some) so
> > I've not had much exposure to the wider module ecosystem and I've point
> > blank refused to 'need' virtual environments for our use.
> 
> FWIW assuming the issues Tim has run into are similar those I'm aware of
> then modulo the general stuff with the 2->3 transition (which was it's
> own special thing) the issues are all in the module ecosystem rather
> than the core language and standard library.

Actually, I need to state that I actually like Python a lot, and it's my preferred
choice for scripting languages.  The main command line tool (and most of
the other utility tools) in Fuego are in Python, and I've worked with it for
many years.  As Mark correctly says, it's the module ecosystem
that drives me nuts, not the language itself, or the core libraries.  But it
does give me heartburn when the community decides to remove a core
library.  And the module ecosystem can't keep itself from using newer
versions of the Python language, so if you have a lot of module dependencies
you will find yourself forced to upgrade your modules (and your own code)
along with the interpreter.

I just don't think that the lead developers have cared enough about backwards
compatibility, and I've made the mistake of using modules which the authors
have, over time, made backwards-incompatible changes to.  This is on the
authors of the individual modules, of course.  But I don't sense very good leadership
to avoid breaking backwards compatibility from the core language developers.

I absolute abhor the virtual environment stuff.  I'd seriously rather
monkey-patch an old library (which I've had to do a few times in Fuego), than force my
users to deal with virtual environments.  Maybe I'm doing something wrong,
but about 50% of the time when I try to use virtual environments on some random
python code I want to play with, I end up having problems (sometimes, quite deep-seated).
To be fair, this may be because I have locked down the versions of the distributions used
in my containers in Fuego (for various reasons too long to go into here), and they are starting
to show their age.  But it really has been a nightmare.

 -- Tim

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

[Robert Schwebel]

Hi,

On Thu, Sep 21, 2023 at 09:46:02PM +0000, Tim Bird wrote:
> Actually, I need to state that I actually like Python a lot, and it's
> my preferred choice for scripting languages. The main command line
> tool (and most of the other utility tools) in Fuego are in Python, and
> I've worked with it for many years. As Mark correctly says, it's the
> module ecosystem that drives me nuts, not the language itself, or the
> core libraries.

I feel your pain. I'm maintaining ptxintranet (our internal business
software for timesheets, invoices etc), a python+django codebase that
has seen almost 15 years of maintenance, and the whole "people change
stuff all the time" drives me crazy. One of the Linux key features for
me as an automation guy was always POSIX, that made it possible to move
away from proprietary microcontrollers to a standard interface, making
it possible to maintain critical control codebases over decades, which
is the timespan that the machine building & automation industry things
of.

However, these days one has to decide: Either for the fancy new world of
hipster code & languages (which all have their own packaging eco-
systems). Or for minimal environments such as POSIX+C or python-without-
the-packaging-ecosystem etc. Both have their advantages and disadvan-
tages, and you can't have it at the same time. With the hipster
languages, you can solve complex problems in a few lines of code. With
the low level variant, you have to invent-here all the standard things
the cool guys have with a handfull lines of code with a lot of effort,
and you have to maintain it over the time.

One thing I personally have learned is: If you use an ecosystem, use it
the way the original authors use it. Don't use it the way you think it
should be used. I tried to build ptxintranet on top of debian packets
for a while, and it was a desaster. Python developers don't care about
Debian, and Debian developers don't care about Python.

These days, my python stuff has a modern pyproject.toml based build
system with the usual pypy dependency mechanics, on top of *only* the
right python core version, using nothing else from the distribution. It
uses a sophisticated pytest testsuite with carefully maintained
coverage, and we follow the Django releases closely, with all the burden
of reading and understanding release notes, fixing test fails etc.

So I made my choice to follow the upstream way of life. It results in
quite some maintenance work, but at least for me, it doesn't feel like a
total desaster.

rsc
-- 
Pengutronix e.K.                           | Dipl.-Ing. Robert Schwebel  |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

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

[Cyril Hrubis]

Hi!
> 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. 

+1

We recently started to work on new tooling for running LTP tests written
in python and after a few up and downs we ended up with using the bare
minimum of modules we can get away with. Less is clearly more in this
context.

-- 
Cyril Hrubis
chrubis@suse.cz

Re: kci command line poll: Click or Typer?

[Guillaume Tucker]

Hi Tim,

On 21/09/2023 21:41, Bird, Tim wrote:
>> -----Original Message-----
>> From: automated-testing@lists.yoctoproject.org <automated-testing@lists.yoctoproject.org> 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.

OK, I see there's 1 vote now.  If that wasn't you then do you
want to get your vote counted from the mailing list?

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

Yes, and I was actually wondering whether we should be doing this
even if we chose to use Click.  We can't do this with all the
other dependencies but the CLI framework is quite important as it
faces users directly.

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

OK so I'm inclined to favour the option of having a first
implementation in Click as that's the easiest to write by far, so
we can deliver the feature according to our current timeline, and
then consider a pure Python one to be immune to breaking changes
in modules.

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

Fair point.  In fact KernelCI provides Docker images with all the
dependencies installed etc. so in practice I don't think anyone
relies on a venv at the moment (either native install or Docker).

> Just my 2 cents.
>    -- Tim

Very valuable ones :)  I was wondering whether users would prefer
the old-school style of Click or the more flashy Typer (as
they're both way better than argparse for implementing lots of
subcommands) but it turns out that users on this thread care more
about Python dependencies management than direct user experience
on the command line.

Thanks,
Guillaume

Re: kci command line poll: Click or Typer?

[Guillaume Tucker]

Hi Cyril,

On 22/09/2023 09:59, Cyril Hrubis wrote:
> Hi!
>> 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. 
> 
> +1

So that's +1 vote count for argparse I guess?

> We recently started to work on new tooling for running LTP tests written
> in python and after a few up and downs we ended up with using the bare
> minimum of modules we can get away with. Less is clearly more in this
> context.

That's very valuable feedback, thanks.  I would expect a similar
kind of audience running the new kci tool as the LTP ones.

Next step, we can start designing a stable kci syntax this week
with commands and arguments regardless of the implementation
framework.  Then next week we'll recap on this discussion to come
up with a plan that maximises both maintainability and user
adoption in the community.

Thanks,
Guillaume

Re: kci command line poll: Click or Typer?

[Guillaume Tucker]

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