fix(ci): tomllib is not stdlib below Python 3.11, but the test matrix runs 3.9
User description
What
pytest collection failed on the Python 3.9 leg of python-tests.yml with:
ModuleNotFoundError: No module named 'tomllib'
for both tests/test_check_drift.py and tests/test_ga_common_github_auth.py, interrupting the whole run on that matrix leg (2 errors during collection, 0 tests executed).
Root cause
tomllib is Python stdlib only from 3.11. This package declares requires-python = ">=3.9" and python-tests.yml's matrix is ["3.9", "3.12", "3.13"] — deliberately added so a version that can install the wheel is also a version whose behavior is asserted. pytest collects every test file in the run regardless of which one is under test, so any file that imports a module doing import tomllib unconditionally breaks collection for the entire 3.9 leg, not just its own tests.
Two release-tooling modules had this: scripts/release/check_drift.py and scripts/ga/ga_common.py. Both did import tomllib unconditionally, even though pyproject.toml already declares "tomli>=2.0.0; python_version < '3.11'" as a dev extra specifically for this case, and tests/test_packaging.py already carries the correct fallback pattern (comment: "tomllib is stdlib from 3.11 only"). These two modules were simply never updated to match.
Fix
Applied the exact same, already-established pattern from tests/test_packaging.py to both modules:
try: # tomllib is stdlib from 3.11; `tomli` is a dev dependency below that (see pyproject.toml).
import tomllib
except ModuleNotFoundError:
import tomli as tomllib
Also updated check_drift.py's module docstring, which claimed "Python 3.11+ ... required" — that was never actually a hard requirement given the tomli extra, and the CI matrix now proves it isn't.
Verification
python3 -m py_compileon both changed files: clean.- Simulated
ModuleNotFoundErrorfortomllibvia a monkeypatched__import__and importedcheck_driftfresh: it fell through totomlicorrectly (check_drift.tomllibresolved to thetomlimodule object). python3 -m pytest -q tests/test_check_drift.py tests/test_ga_common_github_auth.py: 13 passed, 0 failed (run on the locally available Python 3.14, which already hadtomllib; the fallback path itself was proven separately above since no 3.9 interpreter was available in this environment).- No 3.9 interpreter was available in the sandbox this fix was authored in, so the CI matrix itself is the first real 3.9 execution — the change is a minimal, mechanical mirror of
test_packaging.py's already-shipped and already-tested pattern, not new untested logic.
Scope
Two files touched, both additive (a try/except ModuleNotFoundError wrapper around an existing single-line import, plus one docstring correction). No test was weakened, skipped, or had an assertion loosened — this fixes test collection, which is a strict net-positive for coverage (0 tests running on 3.9 -> all tests running on 3.9).
Context
This was investigated as part of a fleet-wide sweep for CI failures across the ~32 WAVE public repos. Measuring gh run list --branch main across every public repo found that only this repo had a genuine current failure on its default branch. sdks' concurrent registry clean-room acceptance failures had already self-resolved (green as of the latest run) before this sweep started. This fix addresses the one real, currently-reproducing failure found, with its own distinct root cause (a Python stdlib version gate, unrelated to any Node/npm NODE_ENV install-skip pattern floated as a leading hypothesis for a fleet-wide story).
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.
[!NOTE]
Low Risk
Additive import compatibility only; no logic or assertion changes beyond enabling the 3.9 CI matrix leg to collect and run tests.
Overview
Fixes pytest collection on Python 3.9 by stopping unconditional import tomllib in scripts/ga/ga_common.py and scripts/release/check_drift.py. Both now use the same try stdlib tomllib / except tomli as tomllib pattern already used elsewhere in the repo, aligned with the existing tomli dev extra for python_version < '3.11'.
check_drift.py's module docstring is updated to describe 3.9+ support (via tomli) instead of implying Python 3.11+ only. Behavior for reading pyproject.toml is unchanged on 3.11+; on 3.9–3.10 imports no longer fail at module load time.
Reviewed by Cursor Bugbot for commit 62f870604c5563ea78a82f719b4048d7cf1d2133. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by Sourcery
Support TOML parsing across all supported Python versions so the complete test suite can run on Python 3.9.
Bug Fixes:
- Restore Python 3.9 CI test collection by falling back to the supported
tomlipackage whentomllibis unavailable.
Enhancements:
- Update release tooling documentation to reflect support across the package’s Python 3.9+ compatibility matrix.
CodeAnt-AI Description
Restore Python 3.9 compatibility for release tooling
What Changed
- Release and GA tooling now reads project metadata on Python versions below 3.11 using the supported TOML compatibility package
- Python 3.9 test collection no longer fails when these modules are imported
- Documentation now reflects support for the full Python 3.9+ compatibility range
Impact
✅ Passing Python 3.9 test runs
✅ Fewer CI collection failures
✅ Release checks work across supported Python versions
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.