Use Rich more broadly?

[mrocklin]

Rich is neat. Do we want to leverage it more broadly?

Dask gets lots of love around our error messages. Good error messages reduce user pain. Rich might help us to improve our current error messages and user feedback. I suspect that once we start using it people might also really enjoy building more with it (it appears to be fun).

However, it would be a new dependency. Do we want to take it on for some of the subprojects like dask.dataframe or dask.distributed?

For context, I created a new conda environment with python installed, and then installed rich and got the following new dependencies

  Package               Version  Build           Channel                     Size
───────────────────────────────────────────────────────────────────────────────────
  Install:
───────────────────────────────────────────────────────────────────────────────────

  + colorama              0.4.4  pyh9f0ad1d_0    conda-forge/noarch        Cached
  + commonmark            0.9.1  py_0            conda-forge/noarch        Cached
  + future               0.18.2  py39h2804cbe_3  conda-forge/osx-arm64     Cached
  + pygments             2.10.0  pyhd8ed1ab_0    conda-forge/noarch        Cached
  + rich                10.12.0  py39h2804cbe_0  conda-forge/osx-arm64     347 KB
  + typing_extensions  3.10.0.2  pyha770c72_0    conda-forge/noarch         28 KB

So, two questions for the group:

1. Where would we use this?
2. How do we feel about the added dependency?

[koaning]

Rich is grand. It's the best thing that happened in python this year. But! There may be downsides to adding it to this project. In particular I would consider:

• Many notebooks that I've used need the ipywidgets dependency for rich to work in a notebook.
• While rich looks amazing in a terminal, it doesn't always translate nicely to a logfile. I especially recall things like Panels causing issues.