bug: Importing from Copier prevents forcing colors with FORCE_COLOR=1

[pawamoy]

Describe the problem

Rich or Rich-based CLIs will print colors on regular terminals. In subprocesses, Rich detects that the process isn't attached to a TTY (or rather pseudo-TTY if I recall terminology correctly) and disables colors. Colors can be forced back using the FORCE_COLOR=1 environment variable.

Setting the variable works well... unless something is imported from Copier. This was quite hard to identify as the cause, but here's a reproduction example:

# colors_without_copier.py
from rich.console import Console
console = Console()
console.print("[bold green]Hello[/]")

# colors_with_copier.py
from copier import run_copy
from rich.console import Console
console = Console()
console.print("[bold green]Hello[/]")

# colors.sh
echo "Forcing colors without Copier imports"
FORCE_COLOR=1 python colors_without_copier.py | cat -n

echo "Forcing colors with Copier imports"
FORCE_COLOR=1 python colors_with_copier.py | cat -n

Now run bash colors.sh and you get an output similar to this (don't pay attention to the actual colors, I'm using a dynamic color theme based on my wallpaper thanks to pywal):

See script in the "Reproduction" section for a complete script that you can copy and paste.

Template

N/A

To Reproduce

cd $(mktemp -d)

cat <<EOF >colors_without_copier.py
from rich.console import Console
console = Console()
console.print("[bold green]Hello[/]")
EOF

cat <<EOF >colors_with_copier.py
from copier import run_copy
from rich.console import Console
console = Console()
console.print("[bold green]Hello[/]")
EOF

cat <<EOF >colors.sh
echo "Forcing colors without Copier imports"
FORCE_COLOR=1 python colors_without_copier.py | cat -n
echo "Forcing colors with Copier imports"
FORCE_COLOR=1 python colors_with_copier.py | cat -n
EOF

bash colors.sh

Logs

No response

Expected behavior

Importing things from Copier should not cancel the effect of FORCE_COLOR=1.

Screenshots/screencasts/logs

No response

Operating system

Linux

Operating system distribution and version

Linux 6.5.7-arch1-1

Copier version

8.3.0

Python version

3.11.5

Installation method

pipx+pypi

Additional context

No response

[pawamoy]

OK, I expanded the imports triggered by from copier import run_copy, and identified the culprit to be copier.tools. Looking at the code, the cause is obvious: colorama.init() is executed at import time. Instead, it should be executed only from the top-level entry-points, possibly with an option to disable it (for library use purposes), and only on Windows. Or we should call colorama.just_fix_windows_console() instead.

To be honest, although Colorama seems super simple to use, every time I have to use it I'm completely lost at how to use it correctly. Here's what I'm doing in another project of mine:

import colorama

def some_entry_point(color: bool | None = None):
    ...
    colorama.deinit()
    colorama.init(strip=None if color is None else not color)
    ...

...which I think is not the most performant way of using it (deinit then reinit every time the function is called), but at least seems to work without messing things up 🤷

[pawamoy]

Reading tartley/colorama#230, my deinit, reinit solution does not seem to be right, since ANSI codes should always be stripped on Windows. I'd therefore recommend using colorama.just_fix_windows_console() instead.

Additional note: from plumbum import colors weirdly adds a trailing line to the output...

[pawamoy]

Plumbum weirdness filed here: tomerfiliba/plumbum#659

[yajo]

Related: #368