Changes between Version 3 and Version 4 of Ticket #31924, comment 4
- Timestamp:
- Aug 25, 2020, 4:18:48 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #31924, comment 4
v3 v4 2 2 > 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]. 3 3 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 does preserve 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.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. 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`. 5 5 6 6 I 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`.