Changes between Version 7 and Version 8 of Ticket #31924, comment 4


Ignore:
Timestamp:
Aug 26, 2020, 1:14:44 PM (4 years ago)
Author:
Zach Waggoner

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #31924, comment 4

    v7 v8  
    22> It looks that Django doesn't recognize that your system's terminal supports color, we have an open ticket to improve detection on Windows, see #31216. You may also fake the installation of `ANSICON` by setting the appropriate environmental variable, `ANSICON="on"`. Please use one of [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels support channels].
    33
    4 I'm on macOS, but I already expect that Django would not recognize that the execution context supports color because it is being run in a non-TTY context (through honcho). The point of `--force-color` is to bypass the color support detection altogether and output colors anyway—''that'' is what I'm saying doesn't work for `runserver`. Running `runserver` directly (not within honcho) ''does'' output colors. Furthermore, running a different management command like `migrate` with the `--force-color` option within honcho preserves the color output, as expected. Therefore the problem is specific to `runserver`.
     4I'm on macOS, but I already expect that Django would not recognize that the execution context supports color because it is being run in a non-TTY context (through honcho). The point of `--force-color` is to bypass the color support detection altogether and output colors anyway—''that'' is what I'm saying doesn't work for `runserver`. Running `runserver` directly (not within honcho) ''does'' output colors. Furthermore, running a different management command such as `migrate` with the `--force-color` option within honcho preserves the color output, as expected. Therefore the problem is specific to `runserver`.
    55
    66I glanced through the source code, and it looks like `django.core.management.base.BaseCommand` handles the `--force-color` option by setting `self.style = color_style(force_color)`. Then the specific commands which inherit from `BaseCommand`, like `migrate`, use `self.style` when writing to stdout. However, `runserver`, while inheriting from `BaseCommand`, doesn't ever reference `self.style`, nor does it do anything else with `--force-color`. Instead, the `style` object is defined in `django.utils.log.ServerFormatter` as `self.style = color_style()`, so `force_color` is ''never'' `True` regardless of any environment variables. That is why I said in my original comment that the current way to solve this is to override `ServerFormatter`, but it seems like Django could support `--force-color` for `runserver`, perhaps by setting an environment variable that is picked up by the default `ServerFormatter`. Or if there are reasons not to do this, then perhaps the documentation should be updated to note that `runserver` does not support `--force-color`. The current docs imply that all management commands support the option.
Back to Top