You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new sdk (python) typechecks job runs mypy --strict --python-version 3.10, not 3.9, because mypy 2.x refuses to target 3.9 at all: mypy: error: argument --python-version: Python 3.9 is not supported (must be 3.10 or higher). 3.10 is the nearest target it accepts, so the declared
floor is checked by nothing.
So the package makes a support claim three interpreter versions wide that no
run has ever tested. A 3.10-only syntax or stdlib call would ship green.
And there is no job in .github/workflows/ci.yml whose python-version is
anything but "3.12" — rg 'python-version' .github/workflows/ci.yml.
What done looks like
Either half is a complete answer; pick one and say which in the PR.
Test the claim. Add a matrix over the declared range to the two Python
SDK jobs — python-version: ["3.9", "3.12"] at minimum, since the floor and
the newest supported are where breakage lives — and, for the typecheck, pin
an older mypy (1.x still targets 3.9) or switch to pyright, which does.
Narrow the claim. Raise requires-python to the lowest version CI
actually runs, and say in sdk/python/README.md what changed. This is a
published-metadata change: it stops pip resolving the SDK for a 3.9 user, so
it needs a version bump and a CHANGELOG.md note.
Constraints
sdk/typescript and sdk/go have the same shape of claim (engines.node: ">=18" against a CI pinned to "22"; go 1.x in go.mod against go-version: "1.22"). Whatever is decided here should be applied to those
two in the same PR or explicitly deferred.
A matrix multiplies job count. The conformance jobs each build the whole Rust
workspace first, so a naive matrix is expensive; a typecheck-only matrix is
nearly free and may be the right first slice.
Found while adding the SDK typecheck jobs in #94 / PR #106.
Problem
sdk/python/pyproject.tomldeclaresrequires-python = ">=3.9". Nothing runsthe SDK, or a typechecker over it, on 3.9, 3.10, or 3.11.
.github/workflows/ci.ymlpinspython-version: "3.12"—
sdk (python) is a conformant implementation,sdk (python) HTTP adapter is conformant,schema validates the examples, and the two jobs PR ci(sdk): typecheck both typed SDKs, and catch a pin that drifted from its manifest #106added.
sdk (python) typechecksjob runsmypy --strict --python-version 3.10, not 3.9, because mypy 2.x refuses to target 3.9 at all:mypy: error: argument --python-version: Python 3.9 is not supported (must be 3.10 or higher). 3.10 is the nearest target it accepts, so the declaredfloor is checked by nothing.
So the package makes a support claim three interpreter versions wide that no
run has ever tested. A 3.10-only syntax or stdlib call would ship green.
How to reproduce
And there is no job in
.github/workflows/ci.ymlwhosepython-versionisanything but
"3.12"—rg 'python-version' .github/workflows/ci.yml.What done looks like
Either half is a complete answer; pick one and say which in the PR.
SDK jobs —
python-version: ["3.9", "3.12"]at minimum, since the floor andthe newest supported are where breakage lives — and, for the typecheck, pin
an older mypy (1.x still targets 3.9) or switch to pyright, which does.
requires-pythonto the lowest version CIactually runs, and say in
sdk/python/README.mdwhat changed. This is apublished-metadata change: it stops pip resolving the SDK for a 3.9 user, so
it needs a version bump and a
CHANGELOG.mdnote.Constraints
sdk/typescriptandsdk/gohave the same shape of claim (engines.node: ">=18"against a CI pinned to"22";go 1.xingo.modagainstgo-version: "1.22"). Whatever is decided here should be applied to thosetwo in the same PR or explicitly deferred.
workspace first, so a naive matrix is expensive; a typecheck-only matrix is
nearly free and may be the right first slice.
Found while adding the SDK typecheck jobs in #94 / PR #106.