1.9 wishlist

[dwreeves]

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

[dwreeves]

I think "Dark mode / light mode detection support" will be out of scope for 1.9. This could be a 2.0 feature alongside significant changes to styling, if it ends up being a feature.

I am also thinking about adding a RichOption() that has Rich-based prompt/confirm; whether to use Rich or Click can be controlled via the RichHelpConfiguration. Note that the help=? kwarg for arguments will also require a RichArgument().

Even though it introduces a new thing into the API that is in a very minor sense potentially breaking, I think it should be fine. This is a very minimal feature, and users utilizing custom Argument and Option subclasses or doing anything else weird should not be impacted, especially if we check isinstance(ctx, RichContext) on the relevant method calls. (I'm actually not sure though how you could pass a non-RichContext into a RichOption though? That may be overkill.)

[ofek]

• Better coupling of the click.HelpFormatter methods and rich-click's implementation, mostly revolving around the buffer.

Handled by #231