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 `coloram` 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
--
Ticket URL: <https://code.djangoproject.com/ticket/31216>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:1>
Old description:
New description:
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
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:2>
* needs_docs: 0 => 1
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:3>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:4>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"f1585c54d0242d71cdc63421f751528472b1c9c2" f1585c54]:
{{{
#!CommitTicketReference repository=""
revision="f1585c54d0242d71cdc63421f751528472b1c9c2"
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.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:5>
* status: closed => new
* resolution: fixed =>
Comment:
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
[https://www.benkuhn.net/importtime/ 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 [https://modwsgi.readthedocs.io/en/master
/configuration-directives/WSGIRestrictStdout.html 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:6>
* status: new => closed
* resolution: => fixed
Comment:
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:7>
Comment (by 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).
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:8>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31216#comment:9>