rich-click
rich-click copied to clipboard
1.9 wishlist
Tentative and subject to change.
First, most importantly, devops:
- code freeze. No feature changes until everything else here is changed.
- switch to ruff for all linting
- completely rewrite unit tests
- use snapshot testing framework, not DIY
- Assert stderr and stdout, not just combined
- Stop passing around functions as fixtures; just use functions normally.
- Add more tests
- add coverage requirements
-
uv pip install --resolution lowest
for CI.
Actual feature additions:
- rst support
- More improvements to the commands/groups:
- I think I want to start the process of deprecating the name "group" and switch to "panel". Group is a bad name as it conflicts with Click's API and causes confusion. I will not be raising deprecation warnings for this until 2.0, but I will phase it out of the documentation. (Perhaps a
PendingDeprecationWarning
). -
panel=?
kwarg for both options and arguments. - Add either
@click.rich_config(panels=[...])
or@click.panel()
. (Or both.) - Descriptions in panels
- I think I want to start the process of deprecating the name "group" and switch to "panel". Group is a bad name as it conflicts with Click's API and causes confusion. I will not be raising deprecation warnings for this until 2.0, but I will phase it out of the documentation. (Perhaps a
-
help=?
kwarg for arguments. - Dark mode / light mode detection support. (This is actually doable, pinky promise!)
- Newline control
- Start taking tab completion more seriously
Potential feature additions, lower priority + speculative + potentially out of scope?:
- Decouple style config and ? I have no idea how this would work though.
- Better coupling of the
click.HelpFormatter
methods and rich-click's implementation, mostly revolving around the buffer. - "Styles". Unclear if I do this, but I want some way to make it easier to get quick style changes. E.g.
{"primary": "blue", "secondary": "red", "tertiary": "yellow"}
. Alternatively, we can make the Live Style Editor do this and not touch the core API. Both are potentially fine. - Optional docstring parsing mode for help text.
- Command aliases
- Optional "didyoumean" support.
My hope is to get all of this done by end of 2024.