How do we feel about adopting rich?

[pradyunsg]

What's the problem this feature will solve?

We're currently using the logging module for handling our output needs. This... works, but is suboptimal since we don't really have any clean way to utilise all the flexibility that a terminal affords us; most notably colors and varying text presentations.

Describe the solution you'd like

Well, part of why I haven't pursued #6541 is that there's no real benefit to doing that without something genuinely beneficial from a UI/UX perspective with that flexibility on the other side.

There weren't any straightforward-and-major presentation gains to be made, by undertaking such a revamp. This is part of why I've let this loiter for so long. With rich though, we would have the required flexibility to actually make meaningful aesthetic improvements available with significantly lower effort (mostly because the required effort was already put into the library).

Alternative Solutions

Maintaining status quo is an option. So, is exploring alternatives to rich that might be more appropriate for our usecase.

I'm wary of directly using something low level though (eg: using colorama directly) since we'd either need to deal with the quirks of the terminal or reimplement many of the features that we'd get with a more rounded-out library like rich.

Additional context

We need to be mindful of our our distribution sizes.

-rw-r--r--  1 pradyunsg  staff   2.6M  3 Sep 10:44 pip-21.3.dev0+rich.tar.gz
-rw-r--r--  1 pradyunsg  staff   1.5M  3 Sep 10:44 pip-21.3.dev0.tar.gz

Most of this ocmes from pygments -- we'll likely need to do something to trim the styles and lexers (~4 MB uncompressed) which we can trim with our vendoring setup. IIUC we don't need any of the web-related styling and only need the lexers related to Markdown and Python.

We'd also need buy-in from the maintainers (/cc @willmcgugan) of rich, since this imposes a couple of restrictions on the library -- it can't adopt non-pure Python dependencies without a graceful fallback and that we're mindful of the sizes of the entire dependency tree.

I had a chat with him a few weeks ago where we talked about this, and he seemed hesitantly excited about the idea. :)

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

Theoretically, we could also just avoid #6541 and just use rich's logging handler: https://rich.readthedocs.io/en/latest/logging.html.

[willmcgugan]

Author of Rich here. Just to say that if you do decide to go down this route, I would be happy to help.

[pradyunsg]

https://github.com/willmcgugan/rich#rich-library provides a good overview of the capabilities, and https://rich.readthedocs.io/en/latest/markup.html is one of the main draws of the library IMO. :)

[uranusjr]

I’m OK with this as long as I’m not the person doing implementation work. Rich is pretty awesome, but I’d imagine the code base will require some serious refactoring to adopt it. And people running things on non-tty environments (e.g. CI) may not be particularly thrilled.

[pfmoore]

I love rich (thanks for all the work you do on it @willmcgugan!), and I'm broadly in support of using it. I do agree we need to be very careful about bloat, though. We should definitely prune anything we currently vendor that duplicates functionality from rich (colorama, progress) which as @uranusjr says will mean a chunk of refactoring. We should also ideally prune unused functionality from rich, but that's true of all of our vendored libraries, so I'd see this as more of a case of adopting rich having emphasized that we can't keep adding dependencies without dealing with distribution size, and therefore take a hard look at all of our vendored dependencies for what we can trim.

From a quick check, it looks like rich is fine for non-tty output:

❯ type .\test.py
from rich import print
from rich.progress import track
from time import sleep

print("[red]Hello, [blue]world")

for i in track(range(100)):
    sleep(0.1)
❯ py .\test.py >outfile.txt
❯ type .\outfile.txt
Hello, world
Working... ---------------------------------------- 100% 0:00:00
❯

So actually, I'd consider this a benefit of rich (we leave the whole tty or not question to rich).

[pradyunsg]

Rich uses colorama under the hood as well. :)

[pfmoore]

Ah, OK. Nevertheless, if we're going to do this, we should remove any direct use we make of colorama in favour of going through rich's abstractions for everything IMO.

[willmcgugan]

I wish I could ditch colorama. It was a fine hack at the time, but the new Windows Terminal doesn't need it. Rich will detect the new Windows Terminal (using a method blessed by the developers) and fallback to colorama if needed.

[notatallshaw]

I wish I could ditch colorama. It was a fine hack at the time, but the new Windows Terminal doesn't need it. Rich will detect the new Windows Terminal (using a method blessed by the developers) and fallback to colorama if needed.

FYI my understanding is the Windows Terminal will be the default command line utility in Windows 11.

At the moment in Windows 10 the user needs to manually download and install the Windows Terminal which in my experience the vast majority of users do not do. Windows 10 consumer support is planned to be ended in 2025.

Sorry if I'm repeating well known information by everyone in this conversation.