Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#7679 closed (fixed)

Colorize 404 and 500 message from runserver to console

Reported by: hunteke Owned by: nobody
Component: django-admin.py runserver Version: master
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: UI/UX:

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 hunteke 7 years ago.
patch: colorize certain console messages, v2

Download all attachments as: .zip

Change History (17)

comment:1 Changed 7 years ago by garcia_marc

  • milestone set to post-1.0
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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

comment:2 follow-up: Changed 7 years ago by mtredinnick

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.

comment:3 in reply to: ↑ 2 Changed 7 years ago by hunteke

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.

Changed 7 years ago by hunteke

patch: colorize certain console messages, v2

comment:4 Changed 7 years ago by hunteke

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 follow-up: Changed 7 years ago by jbalonso

  • Cc jbalonso added

This looks like a duplicate of ticket #6385.

comment:6 in reply to: ↑ 5 Changed 7 years ago by hunteke

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 Changed 7 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:8 Changed 6 years ago by anonymous

  • Cc marco@… added

comment:9 Changed 6 years ago by russellm

  • Patch needs improvement set
  • Triage Stage changed from Design decision needed to Accepted

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 Changed 6 years ago by russellm

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 follow-up: Changed 6 years ago by russellm

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

comment:12 in reply to: ↑ 11 Changed 6 years ago by jezdez

Replying to russellm:

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

Very cool! +1

comment:13 Changed 6 years ago by russellm

  • Resolution set to fixed
  • Status changed from new to closed

(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 Changed 6 years ago by hunteke

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 Changed 6 years ago by russellm

@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 Changed 6 years ago by hunteke

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