Colorize 404 and 500 message from runserver to console

[Kevin Hunter]

I find the normal console output of ./manage.py runserver to be, for the most part, not particularly useful. It's also all a monotone gray. This means that when there is a potentially helpful piece of information (e.g. a 404 or 500 HTTP status), it's easy to miss it in the fray.

This isn't a problem for the big stuff, such as an entire home page, but if a more innocuous request fails, it may be not get spotted quickly. Say, for instance on an ajax request, or for periphery files (Django-munged CSS, JSON, Javascript, etc.)

I can't imagine I'm the only one who appreciates colors, so here ya go.

[Marc Garcia]

Looks nice, but as an out of list improvement, it should be reviewed after 1.0

[Malcolm Tredinnick]

I think this kind of change is a bad idea. Color schemes only work against some backgrounds and when you have perfect vision (or only a particular kind of color blindness). We already have problems that the colorised output from things like "validate" are all but unreadable in some cases, let's not make it worse for normal run-of-the-mill stuff that you're going to be reading all the time when you're developing.

-1 from me.

[Kevin Hunter]

Replying to mtredinnick:
Color schemes only work against some backgrounds

This is a valid argument. I personally use a dark background, and my next-seat coworker uses a white background: it is hard for me to see certain color bits on his background. This is an issue.

and when you have perfect vision (or only a particular kind of color blindness).

This is also a (very) valid argument. However, to play Devil's Advocate, I don't like being forced to an inefficient-for-me work process. On this side of the fence, color is definitely a boon.

We already have problems that the colorised output from things like "validate" are all but unreadable in some cases, let's not make it worse for normal run-of-the-mill stuff that you're going to be reading all the time when you're developing.

As you have rightly pointed out, and validly argued above, this is a problem. However, I don't think it has to be one or the other. A happy middle ground would be, as always, some knob to twist. Perhaps a setting in the local settings.py. COLORIZE_CONSOLE = True or something to that effect.

+1 for the "Design decision needed" stage of this ticket.

[Kevin Hunter]

patch: colorize certain console messages, v2

[Kevin Hunter]

Replying to hunteke:
Perhaps a setting in the local settings.py. COLORIZE_CONSOLE = True or something to that effect.

Python makes this easy, just a roughly 3 line change. I have updated this patch as per this thought process. It now will not output any color to the console unless the COLORIZE_CONSOLE setting has been explicitly set to True in the settings. (In other words, the default is off, and developers must explicitly choose to enable color.)

As implemented, I believe that it resolves the objection by mtredinnick that the colorization behaviour is already broken, even currently.

[jbalonso]

This looks like a duplicate of ticket #6385.

[Kevin Hunter]

Replying to jbalonso:

This looks like a duplicate of ticket #6385.

:-) Your Google is better than my Google. I concur that this ticket is a duplicate.

Notes for the dev who decides the fate of this ticket:

The patch offered in #7679 breaks invocations that do not set the DJANGO_SETTINGS_MODULE variable (e.g. django-admin.py help startproject). #6385 does not break in the absence of this variable.

The patch in #7679 disables console colors entirely unless specifically enabled by the developer as per mtredinnick's gripe.

The patch offered in #7679 is more granular, but covers less ground (only 401, 404, and 500), vs #6385 covers 1xx, 2xx, 3xx, 4xx, and 5xx HTTP response codes.

[(none)]

Milestone post-1.0 deleted

[Russell Keith-Magee]

The issue of disabling/customizing colorization is orthogonal to the original feature request. We already use color on the grounds that it can be a useful UI feature. This ticket is about finding another place we could be using color to good effect.

I've opened #12112 as a feature to enable the disabling/customization of terminal colors.

By way of incentive (and to placate Malcolm's concerns) - I won't personally commit anything for this ticket (#7679) until there is a workable solution for #12112.

[Russell Keith-Magee]

In an example of actual bikeshed painting, here are samples of a ​dark palette and a ​light palette. 2XX SUCCESS messages are color-configurable, but unadorned by default. Opinions?

[Russell Keith-Magee]

Slightly updated bikeshed colors after some initial feedback: ​dark palette ​light palette

[Jannis Leidel]

Replying to russellm:

Slightly updated bikeshed colors after some initial feedback: ​dark palette ​light palette

Very cool! +1

[Russell Keith-Magee]

(In [12085]) Fixed #7679 -- Added (configurable) highlighting colors to the development server. Thanks to Rob Hudson, hunteke, and Bastian Kleineidam for the various patches that contributed to the final result.

[Kevin Hunter]

Good stuff, russellm. Looks real good.

One quick question. I note this text in the changelog:

1001	[ ... ] It won't use the color codes if you're
1002	piping the command's output to another program.

Would there ever be time when folks want color in a pipeline? I ask somewhat leadingly in that I personally like the ability, as for with less. (Made especially necessary if you have more output than fits in your terminal display buffer.) For instance, here's my shell setup for grep and less:

 [file: .bashrc (excerpt)]
export GREP_OPTIONS='--color=none'
alias grep='grep --color=always'  # specifically *not* =auto

alias less='less -R'   # enable pass-through (RAW) colors from grep

Because it's implemented with aliases (not variables), it ensures that scripts won't get messed with, but if I personally type it, I'll get color.

Once again, outstanding. I've gotten used to just editing my personal copy of django, but this is much better, and more thorough. Many thanks.

[Russell Keith-Magee]

@hunteke: There are two use cases here. Firstly is your example - piping through less. In this case, color might be useful.

The other use case is piping commands into other commands (e.g., piping sqlall into a db prompt). In this case, ansi escape codes cause problems, so they need to be disabled.

The current strategy (which predates this ticket by almost 12000+ commits) is to disable color if you're not displaying to a tty. This is an admittedly simple approach, but it works.

Either way, that isn't really related to this ticket specifically - it's a separate feature request. If you want to pursue it, please open a new ticket.

[Kevin Hunter]

:-) Nope. I don't. You've more than done what I originally pointed out could be improved. The last was an idle, "Oh, what about this?". Cheers.