Skip to content

fix: keep termynal color when NO_COLOR is set (e.g. ReadTheDocs) - #39

Merged
0x054 merged 1 commit into
syn54x:mainfrom
FBumann:fix/termynal-no-color
Jun 17, 2026
Merged

fix: keep termynal color when NO_COLOR is set (e.g. ReadTheDocs)#39
0x054 merged 1 commit into
syn54x:mainfrom
FBumann:fix/termynal-no-color

Conversation

@FBumann

@FBumann FBumann commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Sorry for the churn. Only happened in ci on ReadTheDocs...

Closes #38.

Problem

Termynal mode captures a Typer/Click app's --help with color by forcing a terminal in termynal_render._colored_help. The capture Console opts into a palette via force_terminal=True + color_system="standard", but rich's no_color is a separate flag that defaults to ("NO_COLOR" in os.environ). In any build environment that sets NO_COLORReadTheDocs does — every foreground color is stripped and the help renders monochrome. The build still succeeds, so the regression is silent. (FORCE_COLOR=1 does not help: NO_COLOR takes precedence in rich.)

Fix

Pass no_color=False to the capture Console. We've already declared intent to produce color via force_terminal=True + color_system="standard"; this makes that intent robust across build environments. The output here isn't interactive terminal text — it's ANSI converted to HTML spans for a docs page — so honoring NO_COLOR was a category error. The rationale lives in the _colored_help docstring.

Tests

Adds test_render_termynal_html_keeps_color_when_no_color_set, which sets NO_COLOR=1 and asserts color spans survive. Verified it fails without the fix and passes with it. Full termynal suite passes; ruff format --check and ruff check are clean.

A [Unreleased] → Fixed CHANGELOG entry is added.

🤖 Generated with Claude Code

The capture Console in _colored_help opted into a terminal palette via
force_terminal + color_system but left rich's separate no_color flag at
its default of ("NO_COLOR" in os.environ). In build environments that set
NO_COLOR (ReadTheDocs does), foreground colors were silently stripped from
the generated help, even though the output is a build artifact converted
to HTML rather than interactive terminal text.

Pass no_color=False so the declared intent to produce color is robust
across build environments, and add a regression test that renders with
NO_COLOR set.

Closes syn54x#38

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@0x054

0x054 commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

No problem! Thanks.

@0x054
0x054 merged commit e9a451e into syn54x:main Jun 17, 2026
1 of 2 checks passed
@0x054 0x054 mentioned this pull request Jun 17, 2026
2 tasks
0x054 added a commit that referenced this pull request Jun 17, 2026
## Summary

Prepare **0.4.1** for release:

- Bump `version` in `pyproject.toml` to `0.4.1`
- Document the termynal `NO_COLOR` fix merged since `0.4.0` in
`CHANGELOG.md`

## Changes in 0.4.1

- **Fixed:** Termynal mode keeps colors when `NO_COLOR` is set in the
build environment (e.g. ReadTheDocs)
([#39](#39),
[#38](#38))

## After merge

1. Create GitHub Release `v0.4.1` (publish) to trigger PyPI upload via
`publish.yml`
2. Docs site updates automatically on merge to `main`

## Test plan

- [x] Changelog and version bump only
- [x] `uv run pytest` passes locally (109 tests)

Made with [Cursor](https://cursor.com)

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Termynal mode renders monochrome when NO_COLOR is set (e.g. on ReadTheDocs)

2 participants