#32740: Running colorama.init() at import time causes deployment error
-----------------------------------------+---------------------------------
Reporter: Leon Matthews | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Other) | Version: 3.2
Severity: Normal | Keywords: apache mod_wsgi
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+---------------------------------
[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!
--
Ticket URL: <https://code.djangoproject.com/ticket/32740>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/056.3b82235be8659a85db9852342e2a32ea%40djangoproject.com.
