I've been thinking about this one, and I think the best solution is to have a .djangorc file in the user's home directory that contains all the color settings. Sort of like .gitrc and .hgrc and the like. I don't think the colors belong in the settings.py file because it's not really a project-wide setting. You can have multiple users working on the same project, each with their own terminal settings.

Is it completely unheard of for a python module like django to take settings from an .*rc file? How do other frameworks (RoR?) deal with this problem?

The aren't easy to make cross platform (Windows being the black duck),

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.

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.

It's going to be hard to change momentum since [12009], nor do I necessarily think the Django devs should, but I offer this as a suggestion or "data point" in response to nbv4.

This is all by way of saying that one could (and I currently do) use a variable set in a settings file to decide whether to color the console output, that does not affect anyone but me. Further, I can store it in the repo so others can learn about a setting (or anything) they may not typically use.

I typically develop on my laptop, for a server environment. Meaning: settings need to be both global and local (for example, I have a different DB setup, nor do I personally need to load some modules of code that I'm not actively developing). Until we're educated to the Better Way, this is the logic that enables us to have per-machine knobs twisted while maintaining global settings.

Our solution was to use a settings/ directory. This allows us to have multiple settings files that don't pollute the directory structure, and allows us to have to-the-point settings files for different environments. Once we did that, the __init__.py was mandatory, and the rest fell into place.