Consider supporting asyncclick
Description: Rich-click currently doesn't work with asyncclick due to differences in class inheritance and method resolution order (MRO). When using rich-click with asyncclick commands, we encounter exceptions because rich-click's formatting logic doesn't recognize asyncclick's command classes, and we have to do some awkward monkeypatching to get rich formatted help pages working with an async click backend.
Root Cause:
- Rich-click expects standard Click
CommandandGroupclasses. - AsyncClick provides
AsyncCommandandAsyncGroupclasses that inherit from Click but have different MRO - Rich-click's detection/formatting logic doesn't recognize asyncclick command types
- This causes rich-click to not apply its enhanced formatting to async commands
What We're Asking For: Official asyncclick compatibility by:
- Recognizing asyncclick command and group types in rich-click's formatting logic
- Ensuring rich-click's
rich_format_help()works with asyncclick's class hierarchy - Testing compatibility with asyncclick's async command execution
Why This Matters: AsyncClick enables native async/await CLI commands which are essential for applications that need:
- Concurrent operations and async I/O
- Integration with async frameworks (aiohttp, asyncpg, etc.)
- Proper async context management
- Plugin architectures with async lifecycle hooks
We considered wrapping commands in an async context using anyio or trio, but this has drawbacks when it comes to error and context propagation. What we are currnently doing is using a custom AsyncRichCommand and AsyncRichGroup inheriting from the AsyncClick classes, but overriding format_help to call rich_format_help. Though, this works, it's not a good long term solution and I have had to pin to an older version of rich-click because newer versions seem to be incompatible with this approach.
Thanks for the writeup. We'll look into this for the next minor release. Note though that this might take a while to get to.
We will most likely need to do this through some sort of [patch() function]https://ewels.github.io/rich-click/1.9/documentation/rich_click_cli/#using-patch-as-an-end-user). I don't believe anything else would be feasible. This is just a limitation of how the asyncclick people are managing their code.