Customising Click cli help with Rich

[ewels]

I feel like a common setup for rich users is to use the click library to build cli interfaces. The problem with rich making everything so pretty is that the click cli help texts start to stand out as being very... monochrome 😅

I'm thinking that it should be possible to override the click formatter functions (see for example this Stack Overflow question) and was thinking of having a go at writing something as generic and reusable as possible that I could plug into several different projects.

Is this something that would be of interest to add to the rich package? Or is it too far off-scope? (I'm thinking it would be cool to have something similar to the from rich.traceback import install install() functionality). If you think it doesn't fit then I might whip up a tiny PyPI package for it, if I manage to make something half-decent.

Any tips or help from anyone very welcome! Also if anyone knows of something similar already in existence then that would of course be the best solution 💯

[Zethson]

Already answered you somewhere else, but reference implementations:

https://github.com/mlf-core/mlf-core/blob/master/mlf_core/custom_cli/click.py

https://github.com/cookiejar/cookietemple/blob/master/cookietemple/custom_cli/click.py

[willmcgugan]

Hi Phil,

I think it's a good idea! It would be nicer have to closer integration of the two libs, Typer would benefit as well.

I think something like this is better done as an external library. To keep dependencies down to a minimum, but also to reduce the amount of code for me to maintain. Perhaps it could be "rich-click" on Pypi. Or "click-rich".

Just saw @Zethson 's reply. A standalone lib with such functionality would be fantastic.

[willmcgugan]

I think that looks amazing.

I’m not going to have the time to generalise the pretty help stuff in to a package. I’d be delighted if you wanted to tackle it. Let me know if you need any help, and feel free adapt as much as you like!

[ewels]

Alright then, here we go...

• GitHub: https://github.com/ewels/rich-click
• PyPI: https://pypi.org/project/rich-click/

I can't promise that it's well written, or even that it works 😅 But hopefully it's a starting point at least.

Super fun how little code is required with the monkey patching approach.. 😝

[abey79]

Looking great @ewels! Integrating this will be my first task after I push the current release of my project. I'm hoping to contribute on the way. BTW, maybe you could enable Discussions for the project?

[ewels]

Great! Discussions enabled, see you there 🚀

[ssbarnea]

I am not sure exactly what @willmcgugan plans are regarding rich in general but I would like to suggest to welcome rich plugin developers to add their projects under the same organization as rich, following a pattern similar to other organizations: @tox-dev @sphinx-contrib @pytest-dev @apoclyps @click-contrib

I mention this because quote often after I started to use a plugin under a personal account I ended up with maintenance issues, the single point of failure issue.

For rich-click, there also the https://github.com/click-contrib is an option.

I seen that the "grouping" pattern, which is relatively new can really help building a closer community and fostering more collaboration -- tox and pytest being very good examples.

[ssbarnea]

Some time ago I created enrich package which adds few bits I found missing in rich. Feel free to propose a click/typer submodule to it, I use both and I am really interested about more integration.

As maintenance of any package is time consuming, it makes sense to team-up for tasks like this.

Some of the features may endup in rich, some not, but we can easily adapt and avoid cluttering rich itself with non mainstream stuff, especially as initially that new code would likely be... more experimental ;)

[willmcgugan]

Can't say I agree. enrich has been where you implement stuff that I disagree with or think there is a better solution. Which is fine, but bundling that with other features would make them hard to discover.

[ssbarnea]

Indeed, from discoverability point of view separated is better.

Standalone extension ok too, I only wanted to help and mentioned that I am worried about those glue extensions can become unmaintained. I do still have some nightmares about some very useful sphinx extensions that ended being forked and re-released under different names just because original authors lost interest in maintaining them.

@willmcgugan as I seen that you do have an interest in click/typer, I can only expect to see a really nice integration in the future.

[ewels]

Wherever it ends up, more maintainers + repo collaborators etc = better 😄

[MLNW]

Some integration with click would be awesome!