Opened 16 years ago

Closed 14 years ago

Last modified 14 years ago

#7679 closed (fixed)

Colorize 404 and 500 message from runserver to console

Reported by: Kevin Hunter Owned by: nobody
Component: django-admin.py runserver Version: dev
Severity: Keywords: color error http console
Cc: jbalonso, marco@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

colorize_runserver.py.patch (3.1 KB ) - added by Kevin Hunter 16 years ago.
patch: colorize certain console messages, v2

Download all attachments as: .zip

Change History (17)

comment:1 by Marc Garcia, 16 years ago

milestone: post-1.0
Triage Stage: UnreviewedDesign decision needed

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

comment:2 by Malcolm Tredinnick, 16 years ago

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.

in reply to:  2 comment:3 by Kevin Hunter, 16 years ago

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.

by Kevin Hunter, 16 years ago

Attachment: colorize_runserver.py.patch added

patch: colorize certain console messages, v2

comment:4 by Kevin Hunter, 16 years ago

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.

comment:5 by jbalonso, 16 years ago

Cc: jbalonso added

This looks like a duplicate of ticket #6385.

in reply to:  5 comment:6 by Kevin Hunter, 16 years ago

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.

comment:7 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:8 by anonymous, 15 years ago

Cc: marco@… added

comment:9 by Russell Keith-Magee, 14 years ago

Patch needs improvement: set
Triage Stage: Design decision neededAccepted

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.

comment:10 by Russell Keith-Magee, 14 years ago

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?

comment:11 by Russell Keith-Magee, 14 years ago

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

in reply to:  11 comment:12 by Jannis Leidel, 14 years ago

Replying to russellm:

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

Very cool! +1

comment:13 by Russell Keith-Magee, 14 years ago

Resolution: fixed
Status: newclosed

(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.

comment:14 by Kevin Hunter, 14 years ago

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.

comment:15 by Russell Keith-Magee, 14 years ago

@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.

comment:16 by Kevin Hunter, 14 years ago

:-) 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.

Note: See TracTickets for help on using tickets.
Back to Top