fix(deps): lower openai-harmony floor to >=0.0.4 for SGLang compatibility#69
Merged
Conversation
…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>
ApprovabilityVerdict: 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
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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Every SGLang release through the current 0.5.12.post1 hard-pins
openai-harmony==0.0.4(unconditionally, as a direct dependency). renderers' previousopenai-harmony>=0.0.8floor therefore maderenderersandsglangmutually uninstallable in one environment: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.8floor was set in the initial commit with no stated rationale, andGptOssRendereronly uses long-standing harmony APIs. Verified the older harmony is equivalent for our use:tests/test_gpt_oss_harmony_parity.pyis 7/7 green under 0.0.4.uv pip install <renderers> sglang==0.5.10.post1 flash-attn-4now resolves (177 packages) and installsopenai-harmony==0.0.4alongside renderers.harmony's published versions are
0.0.1–0.0.4, 0.0.6, 0.0.8, so>=0.0.4still admits the newest.Change
One line in
pyproject.toml:openai-harmony>=0.0.8→openai-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-harmonydependency floor from>=0.0.8to>=0.0.4sorendererscan install in the same environment as SGLang (which pinsopenai-harmony==0.0.4).pyproject.tomladds a comment documenting that constraint and thatGptOssRenderer/ 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-harmonyminimum version to>=0.0.4for SGLang compatibilityRelaxes the
openai-harmonyfloor in pyproject.toml from>=0.0.8to>=0.0.4so the dependency resolver can select versions compatible with SGLang. Comments are added to document the rationale and parity verification notes.Macroscope summarized 1b183b3.