Skip to content

fix: pin Pygments <2.20 to fix docs build#185

Merged
smoreinis merged 1 commit intomainfrom
fix/pin-pygments-below-2.20
Apr 3, 2026
Merged

fix: pin Pygments <2.20 to fix docs build#185
smoreinis merged 1 commit intomainfrom
fix/pin-pygments-below-2.20

Conversation

@smoreinis
Copy link
Copy Markdown
Collaborator

@smoreinis smoreinis commented Apr 3, 2026

Summary

  • Pins Pygments to >=2.19.2,<2.20 in the docs dependency group to avoid a breaking change in Pygments 2.20.0
  • Pygments 2.20.0 (bumped in build(deps): bump pygments from 2.19.2 to 2.20.0 #182) introduced a regression in HtmlFormatter.__init__ where _decodeifneeded() returns None, causing pymdown-extensions to crash with AttributeError: 'NoneType' object has no attribute 'replace' when rendering function signatures via mkdocstrings
  • This broke the "Build documentation" step in the Release workflow (failed run)

Test plan

  • mkdocs build succeeds locally with Pygments 2.19.2
  • CI Release workflow passes on merge

Greptile Summary

This PR is a targeted dependency fix that pins Pygments to >=2.19.2,<2.20 in the docs dependency group to unblock the docs build broken by a regression introduced in Pygments 2.20.0. The fix is straightforward and correct for its stated purpose.

  • Adds Pygments>=2.19.2,<2.20 to the docs dependency group in pyproject.toml and updates uv.lock accordingly.
  • The upper-bound pin (<2.20) is conservative — using !=2.20.0 would be less restrictive and would automatically pick up any 2.20.x patch that fixes the upstream regression.
  • uv.lock also contains unrelated additions for claude_agent_sdk-0.1.49 (a new sdist entry and an x86_64 wheel) that appear to have been swept in when uv lock was re-run; these are harmless but worth noting.
  • A pre-existing duplicate of agentex-sdk exists in the docs dependency group (lines 60 and 64) — this was not introduced by this PR.

Confidence Score: 5/5

Safe to merge — the change is a minimal, targeted dependency pin that unblocks the docs build with no impact on runtime code.

The change only affects the docs dependency group, has no impact on production or test code, and is well-explained. The only minor concerns are the choice of <2.20 vs !=2.20.0 and the unrelated lockfile entries, neither of which is a blocker.

No files require special attention; both changed files are dependency-management artifacts.

Important Files Changed

Filename Overview
agentex/pyproject.toml Adds Pygments>=2.19.2,<2.20 to the docs dependency group to work around the 2.20.0 regression; note that agentex-sdk is listed twice in this group (pre-existing duplicate).
uv.lock Lockfile updated to reflect the Pygments constraint; also includes unrelated sdist and x86_64 wheel additions for claude_agent_sdk-0.1.49 that were swept in by re-running uv lock.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[mkdocs build] --> B{Pygments version}
    B -- "2.20.0 (broken)" --> C["HtmlFormatter.__init__\n_decodeifneeded() → None"]
    C --> D["AttributeError: 'NoneType'\n.replace() in pymdown-extensions"]
    D --> E[Build fails ❌]
    B -- ">=2.19.2,<2.20 (pinned)" --> F[HtmlFormatter works correctly]
    F --> G[mkdocstrings renders function signatures]
    G --> H[Build succeeds ✅]
Loading
Prompt To Fix All With AI
This is a comment left during a code review.
Path: agentex/pyproject.toml
Line: 63

Comment:
**Consider `!=2.20.0` instead of `<2.20`**

The PR description says the regression is specifically in Pygments 2.20.0. Pinning `<2.20` will also block any future 2.20.x patch releases that might fix the issue (e.g. 2.20.1). Using `!=2.20.0` would be less restrictive and would allow a future patch fix to be picked up automatically.

```suggestion
    "Pygments>=2.19.2,!=2.20.0",
```

If the intent is to stay cautious until upstream confirms a fix, the current `<2.20` pin is acceptable — but worth revisiting once the Pygments team releases a patch.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: uv.lock
Line: 521-527

Comment:
**Unrelated `claude_agent_sdk` lockfile changes**

The diff includes an added `sdist` entry and a new `x86_64` wheel for `claude_agent_sdk-0.1.49` that are unrelated to the Pygments pin. These appear to have been swept in when `uv lock` was re-run. While this is harmless, mixing unrelated lockfile changes makes the PR harder to audit. Consider either reverting those hunks or noting why they are included.

How can I resolve this? If you propose a fix, please make it concise.

Reviews (1): Last reviewed commit: "fix: pin Pygments <2.20 to fix docs buil..." | Re-trigger Greptile

Pygments 2.20.0 introduced a breaking change in HtmlFormatter where
_decodeifneeded() can return None, causing pymdown-extensions to crash
with 'NoneType' object has no attribute 'replace' when rendering
function signatures via mkdocstrings.
@smoreinis smoreinis requested a review from a team as a code owner April 3, 2026 17:30
@smoreinis smoreinis requested a review from danielmillerp April 3, 2026 17:32
@smoreinis smoreinis merged commit 046cdde into main Apr 3, 2026
24 of 28 checks passed
@smoreinis smoreinis deleted the fix/pin-pygments-below-2.20 branch April 3, 2026 23:37
smoreinis added a commit that referenced this pull request Apr 3, 2026
The previous fix (#185) added a Pygments<2.20 constraint to
pyproject.toml but the lockfile was never re-resolved, so CI
continued installing Pygments 2.20.0 which breaks the mkdocs build.
smoreinis added a commit that referenced this pull request Apr 3, 2026
## Summary

- Re-resolves `uv.lock` to actually downgrade Pygments from 2.20.0 to
2.19.2
- The previous fix (#185) added `Pygments<2.20` to `pyproject.toml` but
never re-resolved the lockfile (`uv lock` used a cached resolution), so
CI continued installing 2.20.0
- This is why the docs build is still failing on main — `uv sync --group
docs` installs from the lockfile, which still had 2.20.0

## Test plan

- [ ] CI docs build passes (the `Build Documentation` job that's been
failing)
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.

1 participant