#12112: Allow terminal colors to be customized or disabled
--------------------------------------+-------------------------------------
Reporter: russellm | Owner: nobody
Status: new | Milestone:
Component: django-admin.py | Version: 1.1
Resolution: | Keywords:
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
--------------------------------------+-------------------------------------
Comment (by russellm):
djangorc files have a few problems.
1. The aren't easy to make cross platform (Windows being the black
duck),
2. If we have a djangorc file, we'll start to use it, which could lead
to interesting bugs that only occur because of some setting someone has in
their rc file.
3. We've managed to survive a long time without any need for global
configuration; color really is the first time this has been needed.
So Jacob has confirmed an environment variable as the way to go for this.
Here's a first pass at a spec for someone to code. This is broadly drawn
from the way LS_COLORS works, but is more human-readable:
Colorization will be configurable using a DJANGO_COLORS environment
variable.
Django will ship with 3 built-in 'palettes': light, dark and nocolor.
{{{
DJANGO_COLORS=dark
}}}
would select the dark palette (i.e., colors that can be seen on a black
background). Current default colors correspond to the light palette
(colors that can be seen on a white background). Patch author gets to pick
the color of the bikeshed (literally) for the dark palette, but I reserve
editorial judgement for the core if you pick light puce on mushroom :-)
As well as selecting a predefined palette, colors can be individually
specified:
{{{
DJANGO_COLORS="error=red,bold;warn=blue/white,flashing;notice=green"
}}}
This would define errors as bold red, warnings as flashing blue on a white
background, notices as simple green. (This particular use case wins no
points for aesthetics, but demonstrates syntax).
The 'error', 'warn', 'notice' flags here are the styles that are currently
defined in django/core/management/color.py. These styles may require some
cleanup to make them appropriate for configuration use.
The color names and properties like flash/bold are defined in
django/utils/termcolors.py.
If DJANGO_COLORS doesn't specify a color for a particular style, colors
should fall back to the light palette.
If the user wants to specify a different default palette, that should be
the first entry in DJANGO_COLORS. For example:
{{{
DJANGO_COLORS="dark;error=magenta,bold"
}}}
This would result in the standard dark palette, but with errors bold
magenta.
Existing 'supports_color' logic must to be preserved. Parsing of the
environment variable must be robust -i.e., no runtime exceptions. If a
DJANGO_COLORS definition is unparseable, it should fall back to no colors
at all.
As a guide to implementation - if anything in this proposal proves to be
impractical or impossible, I'm open to revisions. The goal here is to get
easily customizable colors; I'm not hung up on any particular detail
beyond the basics.
This will obviously require some sort of parser for the environment
variable, and this parser will need to have lots of tests as part of the
patch. However, there's no real way to test that the colors will be
correctly applied in normal use, so it's ok to leave the final bit (e.g.,
checking that manage.py sqlall actually writes in color) as an eyeball
test.
--
Ticket URL: <http://code.djangoproject.com/ticket/12112#comment:3>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
