﻿id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32740	Running colorama.init() at import time causes deployment error	Leon Matthews	Carlton Gibson	"[https://code.djangoproject.com/ticket/31216 Ticket 31216] added terminal colour output on Windows. Unfortunately, there is a small problem with it that causes deployments to fail under Linux/Apache/mod_wsgi, leaving me stuck on Django 3.1.

I've tracked it down to line 16 of [https://github.com/django/django/blob/b1a4b1f0bdf05adbd3dc4dde14228e68da54c1a3/django/core/management/color.py#L16 django/code/management/color.py]. There, the function `colorama.init()` is being called, and being called at import time (with caveats, see below).  My deployment setup uses Apache ''mod_wsgi'' with the setting ''WSGIRestrictStdout on'' (its recommended default). During import of the logging system `colorama.init()` accesses `sys.stdout` which is [https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIRestrictStdout.html prohibited by this setting] causing a dreaded 500 error.

Running code during import is [https://www.benkuhn.net/importtime/ best avoided if possible]. I understand that `colorama.init()` must be called at some point, but could it please be moved into a function instead?  Would the function `colour_style()` in the same module be suitable? Doing so would make it possible for me use my logging configuration to avoid the function call.

Some notes:

* My (production) logging configuration doesn't use colour, but the import chain forces a run of `colorama.init()` anyway.
* A work-around would be simply not install colorama, as `init()` is only called it's import succeeds. Unfortunately, colorama is being installed into my project's virtualenv by a 3rd-party dependency, and I don't want to drop that package. Also, I use colorama in the custom management commands of a couple of my projects.
* I apologise for not testing my deployments during the 3.2 beta. I'm kicking myself, because I did test upgrades of my main projects for the beta and release candidates. I fixed all the deprecation warnings and made sure my test suite passed - but I didn't try a test deployment. I fell prey to the classic ''it works on my computer'' blunder!
"	Bug	closed	Core (Other)	3.2	Release blocker	fixed	apache mod_wsgi	MinchinWeb	Ready for checkin	1	0	0	0	0	0
