Skip to content

fix(deps): lower openai-harmony floor to >=0.0.4 for SGLang compatibility#69

Merged
hallerite merged 1 commit into
mainfrom
relax-harmony
May 27, 2026
Merged

fix(deps): lower openai-harmony floor to >=0.0.4 for SGLang compatibility#69
hallerite merged 1 commit into
mainfrom
relax-harmony

Conversation

@hallerite
Copy link
Copy Markdown
Member

@hallerite hallerite commented May 27, 2026

Why

Every SGLang release through the current 0.5.12.post1 hard-pins openai-harmony==0.0.4 (unconditionally, as a direct dependency). renderers' previous openai-harmony>=0.0.8 floor therefore made renderers and sglang mutually uninstallable in one environment:

Because sglang==0.5.10.post1 depends on openai-harmony==0.0.4 and you require
sglang==0.5.10.post1, we can conclude that you require openai-harmony==0.0.4.
And because renderers depends on openai-harmony>=0.0.8, your requirements are unsatisfiable.

This broke the SGLang examples (their inline deps were never satisfiable with renderers>=0.1.6) and blocks any downstream driving gpt-oss through SGLang.

Why it's safe

The >=0.0.8 floor was set in the initial commit with no stated rationale, and GptOssRenderer only uses long-standing harmony APIs. Verified the older harmony is equivalent for our use:

  • Byte-identical render — a tool-using gpt-oss conversation renders to the exact same 149 token ids (and stop ids) on harmony 0.0.4 vs 0.0.8.
  • Parity suite passestests/test_gpt_oss_harmony_parity.py is 7/7 green under 0.0.4.
  • Resolves + installsuv pip install <renderers> sglang==0.5.10.post1 flash-attn-4 now resolves (177 packages) and installs openai-harmony==0.0.4 alongside renderers.

harmony's published versions are 0.0.1–0.0.4, 0.0.6, 0.0.8, so >=0.0.4 still admits the newest.

Change

One line in pyproject.toml: openai-harmony>=0.0.8openai-harmony>=0.0.4, with a comment explaining the SGLang constraint.

🤖 Generated with Claude Code


Note

Low Risk
Packaging-only constraint change with documented parity coverage; no runtime logic changes in this diff.

Overview
Lowers the openai-harmony dependency floor from >=0.0.8 to >=0.0.4 so renderers can install in the same environment as SGLang (which pins openai-harmony==0.0.4).

pyproject.toml adds a comment documenting that constraint and that GptOssRenderer / harmony parity tests are validated on 0.0.4 as well as newer releases.

Reviewed by Cursor Bugbot for commit 1b183b3. Bugbot is set up for automated code reviews on this repo. Configure here.

Note

Lower openai-harmony minimum version to >=0.0.4 for SGLang compatibility

Relaxes the openai-harmony floor in pyproject.toml from >=0.0.8 to >=0.0.4 so the dependency resolver can select versions compatible with SGLang. Comments are added to document the rationale and parity verification notes.

Macroscope summarized 1b183b3.

…lity

Every SGLang release through the current 0.5.12.post1 hard-pins
`openai-harmony==0.0.4`, so renderers' previous `>=0.0.8` floor made it
impossible to install `renderers` and `sglang` into the same environment.
That broke the SGLang examples (their inline deps were unsatisfiable) and
any downstream driving gpt-oss through SGLang.

The `>=0.0.8` floor was introduced in the initial commit with no stated
rationale and is over-conservative. Verified that the older harmony is safe:

- GptOssRenderer renders byte-identically on harmony 0.0.4 — token-for-token
  match vs 0.0.8 on a tool-using gpt-oss conversation (149 ids, identical).
- `tests/test_gpt_oss_harmony_parity.py` passes 7/7 under 0.0.4.
- `uv pip install <renderers> sglang==0.5.10.post1` now resolves and installs
  cleanly (177 packages; harmony 0.0.4, flash-attn-4, flashinfer).

harmony's published versions are 0.0.1-0.0.4, 0.0.6, 0.0.8, so `>=0.0.4`
still allows the newest.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@macroscopeapp
Copy link
Copy Markdown

macroscopeapp Bot commented May 27, 2026

Approvability

Verdict: Approved

This PR lowers a dependency version floor for compatibility with SGLang, with no runtime behavior changes. The change is well-documented and the author is the primary maintainer of the affected file.

You can customize Macroscope's approvability policy. Learn more.

@hallerite hallerite merged commit 1569dc9 into main May 27, 2026
11 checks passed
@hallerite hallerite deleted the relax-harmony branch May 27, 2026 17:01
hallerite added a commit that referenced this pull request May 27, 2026
…e from Tokenizer

Brings in #68 (examples), #69 (harmony floor), #71 (qwen3.5 hard-coded
enable_thinking). The only qwen35.py conflict is resolved by keeping #71's
hard-coded `_ENABLE_THINKING_DEFAULTS` table (no `apply_chat_template`
probe) on top of #31's `Tokenizer`/`Processor` type hints.

Now that #71 removed the last hand-coded-renderer call to
`apply_chat_template`, drop it from the `Tokenizer` protocol so a plain
`tokenizers.Tokenizer` wrapper satisfies it. `apply_chat_template` moves to
a new `ChatTemplateTokenizer(Tokenizer, Protocol)` subtype, required only by
`DefaultRenderer` (the generic chat-template fallback).
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