Hi Adam 👋

I've made a few changes to the image shared on twitter a few days ago. I've added Color to the test output and customised the lines above and below the test headings (ft. a Django shade of green).

I was unsure how best to test this. In my little package I created a test project (included here for demo purposes -- will need refinement) then ran it using subprocess and captured the output. I'd appreciate your guidance on how you'd like the tests approached. I saw you were using call_command but that did not seem to work for me when the command is test

updates:

• github.com/asottile/pyupgrade: v2.38.2 → v3.0.0
• github.com/psf/black: 22.8.0 → 22.10.0
• github.com/pre-commit/mirrors-mypy: v0.981 → v0.982

Bumps actions/setup-python from 3 to 4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Description

Rich has "pretty" mode that can be installed in the plain python repl, and in ipython:

https://rich.readthedocs.io/en/latest/introduction.html?highlight=install#rich-in-the-repl

We could extend manage.py shell to use that automatically.

Description

While writing a test for a RichCommand management command, I ran into trouble on the CI, because inside a Rich Table, the column headers were cropped from Maximum Value to Max….

First, I couldn't reproduce this locally, since my console width was at about 300 characters. On the CI, however, it as just 80 chars.

I now have a mixin for my test cases that allows me to set some console configurations:

from contextlib import contextmanager
from functools import partial
from unittest import mock
from rich.console import Console

class RichConsoleMixin:
    @contextmanager
    def patch_console(self):
        with mock.patch(
            "django_rich.management.RichCommand.make_rich_console",
            partial(Console, width=200),
        ):
            yield

Usage:

class TestMyCommand(RichConsoleMixin, TestCase):
    def test_call(self):
        stdout = io.StringIO()
        with self.patch_console():
            call_command("my_command", stdout=stdout)
        out = stdout.getvalue()
        self.assertIn("Maximum Value", out)

It might be convenient to have a similar mixin available as part of rich-django.

Hi Adam -- me again 😄

So there's a few design choices I've made.

The first is in the output we can give. For simplicity the test timings will only be output at the end of the test run. The cPython patch would allow them to be inlined when running verbose mode but as far as I can tell that would require folk to use a custom TestCase. That breaks the simplicity of "add a setting" to get up and running.

The second is how you enable it. There's various options, I've currently gone with pass in --timing to get it to output, and if verbosity is increased then you get more tests. There's more complex options e.g. add a new flag e.g. --duration and allow it to pass in a value, but that adds complexity especially if this could make it's way into Django core one day. Another option I considered was to always output the slowest tests (we're capturing it anyway).

I am hoping this is a better quality patch at the first pass than last time. I'm hopeful to see the magic green tick shortly. (I suspect Django 2.2 may have something to say about that).

Ah, finally I think there's a few missing items in typeshed so a number of #ignores dotted about.

p.s. that regression test is slow 🕵️

Description

By default Rich’s progress uses len(iterable) to get the number of objects. This is not performant, and at least QuerySet.count() could be used for querysets. Perhaps there could also be more help in a wrapper.