1.9 integration testing

[dwreeves]

Some libraries that use rich-click extensively that we'd like to test manually for 1.9 to ensure that nothing breaks.

1.9 makes significant changes to the internals, but should not be breaking at the high-level API.

Checkboxes represent validation that everything works.

As of writing, 1.9.0dev0 isn't feature-stable so no tests performed.

Test cases are decided based on two main factors:

• Popularity of the library (i.e. impact for breaking changes larger)
• Complexity of feature set used (e.g. use of options/command groups, subclassing RichComamands)

Test cases

• https://github.com/litestar-org/litestar
• https://github.com/pathintegral-institute/mcpm.sh
• https://github.com/tconbeer/harlequin
• https://github.com/apache/airflow (breeze CLI) Too hard to test.
• https://github.com/MultiQC/MultiQC
• https://github.com/bowtie-json-schema/bowtie
• https://github.com/flyteorg/flyte-sdk
• https://github.com/flyteorg/flytekit
• https://github.com/espressif/esptool
• https://github.com/SearchSavior/OpenArc

[dwreeves]

Integration testing 1.9.0.dev2

Open two terminals with:

alias uv_run='uv run --with "rich-click<1.9.0"'

alias uv_run='uv run --with "rich-click>=1.9.0.dev5"'

uv_run --with litestar litestar --help
uv_run --with litestar litestar run --help
uv_run --with harlequin harlequin --help
uv_run --with multiqc multiqc --help
uv_run --with bowtie-json-schema bowtie --help
uv_run --python 3.12 --with flytekit pyflyte --help
uv_run --with esptool esptool --help
uv_run --python 3.12 --with "git+https://github.com/SearchSavior/OpenArc" openarc --help
uv_run --with mcpm mcpm --help
uv_run --with mcpm mcpm run --help

Notes:

• bug with modern theme (oops) replace \\] with ]
• metavar append becomes [] instead of ().
  • Probably revert this for the box theme.
• epilog in multiqc looks strange without bottom padding.
• Newlines no longer work: uv_run --with mcpm rich-click mcpm run --help

[dwreeves]

Integration test failure:

Some subclasses override add_command() but do not have aliases or panels in accepted kwargs.

self.add_command(cmd, aliases=aliases, panel=panel)

Most notably, litestar:

RICH_CLICK_THEME=star uv run --with "rich-click==1.9.0.dev4" --with litestar litestar --help

Some additional work will be needed to resolve this as we simply cannot break litestar like this.

[dwreeves]

esptool has some issues. Everything else looks good.

[dwreeves]

Done with integration tests.

[peterdragun]

Hi @dwreeves, first of all, thank you for developing such a nice package and also for including the esptool in your integration tests.

esptool has some issues. Everything else looks good.

I am not sure what kind of issues you were facing, but I was testing your new version with esptool as well, and in one sub-script, I am getting output to be written to /dev/null instead of stdout/stderr as I would expect. I believe that this might be an issue with the new version of rich_click. Can you please elaborate a bit more on what issues you were seeing?

[dwreeves]

Hi @peterdragun,

That was not the issue I encountered. I was running into an issue with the command "groups" not working (my fault, not yours). In the latest commit, I fixed the issue.

I believe I know what you may be referring to with the /dev/null issue; I'll get a moment to check later, but can you help me out by answering this question; is it possible you are using the ctx.console inside of the command itself?

We changed how the console writes in 1.9 so that help text is written atomically; also so that it is written the same place and time that base click writes.

Fear not, it's fixable, we can have our atomic cake and eat it too. We can hotfix things so that if --help is not invoked, the console does not write to /dev/null.

cc @ewels let's hold off on release until we look into this, but I believe this should be a quick fix.

[peterdragun]

is it possible you are using the ctx.console inside of the command itself?

I don't think we modify the console in any way. This only happens for one of the scripts - espefuse --help - the other two (esptool and espsecure) work well. But this is the one where we are using the API of Click quite extensively.

We changed how the console writes in 1.9 so that help text is written atomically; also so that it is written the same place and time that base click writes.

This might be a hint at what could be the issue - we have implemented "dynamic" commands, and we call a slightly modified get_help function, see: https://github.com/espressif/esptool/blob/master/espefuse/cli_util.py#L233

I am still investigating if this is an issue on our end or something in the rich_click, but based on the git bisect, I was able to find a commit that caused this issue: 8d39c0e

Thanks for your cooperation.

[dwreeves]

Ah got it, so not an issue with ctx.console. (I wasn't asking if you modified the console, just if you ever used ctx.console within a command execution)

Unfortunately, I am not 100% sure what to do about this... 😬 So the new behavior is we defer writing help text; this aligns our behavior more closely with Click and has advantages when it comes to third-party tools + it makes help text atomic.

This is the source of the issue-- basically, the help text needs to be printed explicitly, but you aren't printing it.

This would unfortunately necessitate a slight change to your library. @peterdragun We can get a fix in quickly (I can assist), or you can restrict the version to <1.9 until a fix is in.

Thanks for your assistance on this.