Changes between Version 1 and Version 2 of Ticket #31924, comment 4


Ignore:
Timestamp:
Aug 25, 2020, 3:26:19 PM (4 years ago)
Author:
Zach Waggoner

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #31924, comment 4

    v1 v2  
    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, so if what you are saying is true, then perhaps we need to open a ticket to improve detection on macOS? However, I don't think that is the problem, because running `runserver` directly (not in a non-TTY context like honcho) ''does'' output colors. Furthermore, running a different management command like `migrate` with the `--force-color` option also preserves the color output when run through honcho. Therefore the problem is specific to `runserver`.
     4I'm on macOS, so if what you are saying is true, then perhaps we need to open a ticket to improve detection on macOS? However, I don't think that is the problem, because running `runserver` directly (not in a non-TTY context like honcho) ''does'' output colors. Furthermore, running a different management command like `migrate` with the `--force-color` option also preserves the color output when run through honcho. Therefore the problem is specific to `runserver`, and besides, I thought the point of `--force-color` is to bypass the color support detection altogether.
    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`.
Back to Top