At the pytest sprint, we discussed making pytest's output more modern (and digestable), drawing inspirations from projects such as:
However, at least for a first step, we want to keep the output similar "in spirit" to what it is now, perhaps with minor improvements like using unicode (if available) to draw lines instead of the current ASCII-based lines.
To do so, we want to drop our custom terminal formatting code in the long run and switch to rich. However, such a switch might be problematic, especially given that rich also uses pytest (and if they break something, they might be unable to run their testsuite). Then again, we depend on pygments and colorama and that has never been much of a problem.
To ease into this, we discussed about the following approach:
- Have
rich as an optional dependency (sadly we don't have default extras quite yet), and have a second internal terminalreporter plugin that takes over (and uses rich for output) if it is installed. It should replicate the current output to a high degree, but based on rich.
- At some point, make the new
rich terminal reporter the default, and add rich as a hard dependency for pytest
- Perhaps add a fallback mode if something goes wrong with rich, where pytest shows barebones output and a warning (no lines etc., but still enough to use it if absolutely required)
- Decide what to do with the low-level
TerminalWriter. We might still want to keep it as a thin shim around rich. It seems to be private API, however (pytest_terminal_summary gets terminalreporter, and TerminalReporter has a private _tw object).
cc @willmcgugan as a heads-up
At the pytest sprint, we discussed making pytest's output more modern (and digestable), drawing inspirations from projects such as:
However, at least for a first step, we want to keep the output similar "in spirit" to what it is now, perhaps with minor improvements like using unicode (if available) to draw lines instead of the current ASCII-based lines.
To do so, we want to drop our custom terminal formatting code in the long run and switch to
rich. However, such a switch might be problematic, especially given thatrichalso uses pytest (and if they break something, they might be unable to run their testsuite). Then again, we depend onpygmentsandcoloramaand that has never been much of a problem.To ease into this, we discussed about the following approach:
richas an optional dependency (sadly we don't have default extras quite yet), and have a second internalterminalreporterplugin that takes over (and uses rich for output) if it is installed. It should replicate the current output to a high degree, but based on rich.richterminal reporter the default, and addrichas a hard dependency for pytestTerminalWriter. We might still want to keep it as a thin shim around rich. It seems to be private API, however (pytest_terminal_summarygetsterminalreporter, andTerminalReporterhas a private_twobject).cc @willmcgugan as a heads-up