fix(ci): tomllib is not stdlib below Python 3.11, but the test matrix runs 3.9 - #55
fix(ci): tomllib is not stdlib below Python 3.11, but the test matrix runs 3.9#55yakimoto wants to merge 1 commit into
Conversation
… runs 3.9 python-tests.yml added a pytest matrix of 3.9/3.12/3.13, and pytest collects every test file regardless of which one is under test. tests/test_check_drift.py and tests/test_ga_common_github_auth.py both import (directly or transitively) scripts/release/check_drift.py and scripts/ga/ga_common.py, both of which did `import tomllib` unconditionally — a module stdlib only from Python 3.11. Collection failed with ModuleNotFoundError on the 3.9 leg, interrupting the whole run (2 errors during collection, 0 tests executed on that leg). pyproject.toml already declares `tomli>=2.0.0; python_version < '3.11'` as a dev dependency, and tests/test_packaging.py already uses the try/except ModuleNotFoundError fallback — this applies the same, already- established pattern to the two release-tooling modules that were missing it.
There was a problem hiding this comment.
Sorry @yakimoto, this account has used its review budget of 2,500,000 diff characters for the last 7 days.
You can request another review in 1 day and 3 hours by commenting @sourcery-ai review.
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_8b8af8c1-5f04-47fe-8b0f-d8b8af795521) |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideThe PR fixes Python 3.9 test collection failures by making both release-tooling modules use Flow diagram for Python-version-compatible TOML loadingflowchart TD
Import["Release tooling imports TOML parser"] --> Available{"tomllib available?"}
Available -->|Yes| Stdlib["Use stdlib tomllib"]
Available -->|No: Python below 3.11| Fallback["Use dev dependency tomli as tomllib"]
Stdlib --> Continue["Module loads and pytest collection continues"]
Fallback --> Continue
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Note Automatic reviews are paused because your team has used its included automatic processing for this billing period (headroom scales with your seat count). You can still comment "Gitar review" to run one anytime, and automatic reviews resume on their own by October 1. Add seats for more headroom. Code Review ✅ ApprovedFixes pytest collection failure on Python 3.9 by adding OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🔇 Additional comments (2)
📝 SummarySummary by CodeRabbit
WalkthroughThe scripts now support TOML parsing on Python 3.9–3.10 by using ChangesTOML compatibility
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The release and GA scripts can now parse TOML on Python 3.9–3.10 while retaining the standard-library parser on newer Python versions. No current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
ApprovabilityVerdict: Would Approve Macroscope's review found this PR approvable — This is a narrowly scoped CI compatibility fix that lets existing GA and release checks run on Python 3.9–3.10 using the already-declared Not approved because:
Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more. |
|
ⓘ Qodo reviews are paused because your workspace is out of credits. Ask your workspace admin to add credits to resume reviews. Manage billing |
There was a problem hiding this comment.
No issues found across 2 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Architecture diagram
sequenceDiagram
participant CI as CI Runner (python-tests matrix)
participant Py as Python Interpreter
participant Module as Changed Scripts (ga_common.py / check_drift.py)
participant TomlLib as tomllib (stdlib 3.11+)
participant Tomli as tomli (fallback < 3.11)
participant DevExtra as pyproject.toml dev dependency
participant Pkg as Package metadata (pyproject.toml)
participant TestFile as Test Files
Note over CI,TestFile: Python 3.9-3.10 execution path
CI->>Py: Initialize Python 3.9
Py->>TestFile: Collect test files
TestFile->>Module: Import module for collection
Module->>Module: Attempt import tomllib
Module->>TomlLib: import tomllib
alt Python 3.11+ (tomllib available)
TomlLib-->>Module: Module loaded successfully
else Python 3.9-3.10 (ModuleNotFoundError)
TomlLib-->>Module: ModuleNotFoundError raised
Module->>DevExtra: Check dev dependency availability
DevExtra->>Tomli: tomli installed via dev extra
Module->>Tomli: import tomli as tomllib
Tomli-->>Module: Module loaded as fallback
end
Module->>Pkg: Parse pyproject.toml metadata
Pkg-->>Module: Return package configuration
Module-->>TestFile: Import successful, tests can run
Note over CI,TestFile: Debug/git operations in check_drift.py
Module->>Module: git/gh CLI operations for drift checking
Module-->>TestFile: Check drift results
Note over CI,TestFile: New behavior validated
CI->>Py: All tests in matrix leg execute
Py-->>CI: Test results (pass/fail)
Note over Module,Tomli: Key architectural boundary
Note over Module,Tomli: TOML parsing abstraction layer
Note over Module,Tomli: Same interface via alias, different backends
User description
What
pytestcollection failed on the Python 3.9 leg ofpython-tests.ymlwith:for both
tests/test_check_drift.pyandtests/test_ga_common_github_auth.py, interrupting the whole run on that matrix leg (2 errors during collection, 0 tests executed).Root cause
tomllibis Python stdlib only from 3.11. This package declaresrequires-python = ">=3.9"andpython-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.pytestcollects every test file in the run regardless of which one is under test, so any file that imports a module doingimport tomllibunconditionally breaks collection for the entire 3.9 leg, not just its own tests.Two release-tooling modules had this:
scripts/release/check_drift.pyandscripts/ga/ga_common.py. Both didimport tomllibunconditionally, even thoughpyproject.tomlalready declares"tomli>=2.0.0; python_version < '3.11'"as adevextra specifically for this case, andtests/test_packaging.pyalready 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.pyto both modules:Also updated
check_drift.py's module docstring, which claimed "Python 3.11+ ... required" — that was never actually a hard requirement given thetomliextra, and the CI matrix now proves it isn't.Verification
python3 -m py_compileon both changed files: clean.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).test_packaging.py's already-shipped and already-tested pattern, not new untested logic.Scope
Two files touched, both additive (a
try/except ModuleNotFoundErrorwrapper 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 mainacross every public repo found that only this repo had a genuine current failure on its default branch.sdks' concurrentregistry clean-room acceptancefailures 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/npmNODE_ENVinstall-skip pattern floated as a leading hypothesis for a fleet-wide story).Need help on this PR? Tag
@codesmith-botwith 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 tomllibinscripts/ga/ga_common.pyandscripts/release/check_drift.py. Both now use the same try stdlibtomllib/ excepttomli as tomllibpattern already used elsewhere in the repo, aligned with the existingtomlidev extra forpython_version < '3.11'.check_drift.py's module docstring is updated to describe 3.9+ support (viatomli) instead of implying Python 3.11+ only. Behavior for readingpyproject.tomlis unchanged on 3.11+; on 3.9–3.10 imports no longer fail at module load time.Reviewed by Cursor Bugbot for commit 62f8706. 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:
tomlipackage whentomllibis unavailable.Enhancements:
CodeAnt-AI Description
Restore Python 3.9 compatibility for release tooling
What Changed
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:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
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:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
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.