ANSI Color support

Description

• Easy ability for both internal code and users to specify that (at least) full lines are a given ANSI color, if not words or arbitrary parts of output strings.
• Global flag for disabling ANSI so that anyone who cares can turn it off (e.g. for someone scripting Fab itself, or whatever.)
• Have various internal output calls make use of color so that e.g. “executing task X” lines are blue, running lines are…uh…yellow? green?, aborts/errors are red, and etc etc etc.

Be nice to leverage an external library for this instead of reinventing the wheel for the actual mechanics – see what’s out there.

---

ok, there is a handful of prior art:

• Django termcolors.py
• colorize.py
• console.py
• colorama - Kr recommended
• Clint - not sure if Kr is using colorama in this but it does do color =) see also #363
• Fabulous
• Blessings

General ideas:

• Unary functions. print(red(blink("text") + "non blinking text")) etc. Seems easy enough to use, possibly some tricky spots in actual implementation – check Term::ANSIColor (source) for ideas, maybe.
• Dead simple mapping of the codes to constants/vars. (Possibly why nobody’s done a lib for this – it’s dead simple.) E.g. print(RED + BLINK + "text" + CLEAR + RED + "non blinking text" + CLEAR).

ANSI code maps:

• Pueblo MUD client list
• Another list from a Ruby implementation
• Wikipedia

More notes:

• there are apparently issues with this on Windows terminals, so may want/need an automatic if win32: env.disable_colors = True sort of thing.
• have regular expressions that can trigger certain highlights, so that e.g. stdout/stderr matching “error messages” can be colored red or whatnot. I.e. “Permission denied” and the like. (see also: capistrano-colors)
• if/when we do logging (#57) it may make sense to turn colors off for the logs – or make it an option in case anybody actually wants the ANSI codes in their log files.

---

Current status:

• Implemented a barebones in-house lib as fabric.colors in Fabric 0.9.2
• Not using it anywhere in Fabric core yet; only place I use it myself is in one seldom used task
• May still be worth using a 3rd party lib if/when we get around to seriously leveraging color in Fabric itself
  • However, unless a bridge is provided to the current included colors module, doing so is likely to break backwards compatibility
  • So either write such a bridge, don’t bother using a 3rd party lib, or wait to do so till 2.x

---

Originally submitted by Jeff Forcier (bitprophet) on 2009-11-11 at 05:46pm EST

Relations

• Related to #151: Make fabfile print() statements controllable via output controls
• Related to #240: Use background colors in fabric.colors
• Related to #57: Support full logging to file
• Related to #363: Consider integrating Clint

[edbrannin]

For people like me running Windows and trying to get things like run("ls --color") to look good, I’d like to note that this works:

1. Install the colorama module (pip install colorama)
2. Add this code to fabfile.py:

try:
    import colorama
    colorama.init()
except ImportError:
    print "WARNING: Some tasks may be hard to read unless you install colorama."

[exhuma]

I’ve added PR pyinvoke/invoke#663 to support this. Notice that this is primarily a PR to get the ball rolling again. It does not use any of the mentioned libraries because it is not yet clear to me how they should be integrated. See the notes on pyinvoke/invoke#663

I am absolutely willing to replace my own code with a third-party library.