Support terminal color output on Windows via colorama

[MinchinWeb]

If colorama is installed (as on Windows), support colored terminal output.

There is a very old ticket (https://code.djangoproject.com/ticket/13476) discussing how to support colorized terminal output on Windows. At the time, ANSICON was chosen as a solution over colorama. However, the link provided for ANSICON (​http://adoxa.hostmyway.net/ansicon/) no longer works, and, personally, I struggled to install it previously (it involved messing around with DLL's and some fairly low level Windows functionality). colorama, on the other hand, is a current Python package that provides color on Windows by converting the ANSI cods to Windows native color "codes"; on other platforms, it just passes through the ANSI codes through. colorama is also very popular: for example, it is vendored by pip (​https://github.com/pypa/pip/tree/master/src/pip/_vendor).

What this change does is test to see if colorama is available, and activate color (on Windows) if it is. It is not a hard dependency or even added to the "install_requires" of setup.py. Personally, I would support adding colorama as a dependency on Windows, but I wasn't sure how much support there would be for that.

No documentation changes have been added, although I think this would be wise to mention in the installation instructions for Windows. No tests have been added either, but I'm not really sure what to test directly. If someone could point me to where to make those changes, I would be happy to.

Pull Request: ​https://github.com/django/django/pull/12387

[GitHub <noreply@…>]

In f1585c54:

Fixed #31216 -- Added support for colorama terminal colors on Windows.

Modern setups on Windows support terminal colors.
The colorama library may also be used, as an
alternative to the ANSICON library.

[Leon Matthews]

This change has caused a 500 error on my sites because of the call to colorama.init() at import time. It is now preventing me from upgrading to Django 3.2 (it still works fine on Django 3.1.10).

I understand that colorama.init() must be called at some point, but could it please be moved into a function instead? Maybe colour_style()? Running code at import time is usually bad practice, and can cause ​lots of problems. In my case it is causing my server process to crash before it has a chance to be configured. My logging configuration doesn't use colour, but the import chain forces a run of colorama.init() anyway.

I am running Ubuntu Server 20.04, Python 3.8, Apache2 and mod_wsgi with WSGIRestrictStdout set to its default value of on. It is the latter that is the proximate cause of the problem as colorama accesses sys.stdout which is ​prohibited by mod_wsgi

Thank you very much - and I hope this is the right place to bring this up. I was able track my problem down to this patch, so I haven't created a new issue.

[Claude Paroz]

Hi Leon,

Thanks a lot for the report, but instead of reopening a closed ticket, could we please ask you to create a new ticket with your report?

[Carlton Gibson]

I am running Ubuntu Server 20.04, Python 3.8, Apache2...

Hey Leon... Pending a follow-up ticket, colorama is to provide syntax colouring on Windows. The simplest thing here as an immediate workaround is to not install it on Ubuntu (or uninstall it since it's already there).

[Leon Matthews]

Hey Leon... Pending a follow-up ticket, colorama is to provide syntax colouring on Windows. The simplest thing here as an immediate workaround is to not install it on Ubuntu (or uninstall it since it's already there).

Thank you for the suggestion. That had occurred to me as well. As it happens, it's being installed into the project virtual environment not directly, but as a dependency pulled in from some other package. It's morning in my timezone now (warm greetings from New Zealand!), so I'm raising a new ticket (sorry for going the wrong way) to help get it fixed properly.