chore: drop Python 3.9 support - #300
Merged
mergify[bot] merged 2 commits intoAug 28, 2026
Merged
Conversation
Mergify reads its configuration from the default branch, so a pull request that removes 3.9 from the CI matrix would still be gated on a `Test with Python 3.9` check run that no longer exists, and could never merge. Drop the requirement first, on its own, exactly like #142 did before 3.8 was dropped in #140. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XkWQRxh5pfi2Fbuv3Z9wen Change-Id: I2e80afa6a0e70ac049da3512f43185a57a744e50
Python 3.9 has been end-of-life since October 2025 and no known consumer of sql-compare is still on it: the monorepo `engine` and `shadow-office` both declare `requires-python = "~=3.14.0"`. Dropping it unblocks dependencies that already require 3.10, starting with sqlparse 0.6.0. This also removes the CI workaround that existed only for 3.9. Poetry 2.4.1 needs Python >=3.10, so the job installed it under a pinned 3.12 and pointed it at the matrix interpreter with `poetry env use`. With a 3.10 floor a single `setup-python` is enough. Without `poetry env use`, though, poetry picks its interpreter off PATH, and every matrix version satisfies `python = "^3.10"` - so a wrong pick would test one version three times and stay green. The added assertion makes that fail loudly instead. `[tool.ruff] target-version` is dropped so ruff infers it from `requires-python`. It said "py312" while the floor was 3.9 and would have said it while the floor is 3.10; with `preview = true` and `UP` selected, that makes ruff raise UP040/UP046 with fixes that emit PEP 695 syntax (`type X = int`, `class Box[T]`), which is a SyntaxError on the 3.10 and 3.11 legs. Inferring keeps the two in sync permanently. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XkWQRxh5pfi2Fbuv3Z9wen Change-Id: I220426d76c471b02a2dc667a816cf2d171da0033
This was referenced Aug 27, 2026
Member
Author
|
This pull request is part of a Mergify stack:
|
Contributor
Merge Protections🟢 All 7 merge protections satisfied — ready to merge. Show 7 satisfied protections🟢 ⛓️ Depends-On RequirementsRequirement based on the presence of
🟢 🤖 Continuous Integration
🟢 👀 Review Requirements
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 Reviews
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
sileht
marked this pull request as ready for review
August 27, 2026 15:19
Base automatically changed from
devs/sileht/sqlparse-0.6/don-t-check-python-3-9-tests--2e80afa6
to
main
August 27, 2026 15:24
remyduthu
approved these changes
Aug 28, 2026
Contributor
Merge Queue Status
This pull request spent 2 minutes 2 seconds in the queue, including 58 seconds running CI. Required conditions to merge
|
44 tasks
mergify
Bot
deleted the
devs/sileht/sqlparse-0.6/drop-python-3-9-support--220426d7
branch
August 28, 2026 08:35
mergify Bot
pushed a commit
that referenced
this pull request
Sep 3, 2026
The two matrix legs added in the previous commit are advisory on their own. `.mergify.yml`'s `&CheckRuns` anchor is this repository's only merge gate: `branches/main/protection` returns no `required_status_checks`, and none of the eleven active rulesets carries one. So a red 3.13 or 3.14 leg would land silently. The ordering mirrors #299 -> #300 but not the reasoning, which is worth stating rather than assuming symmetric. Removing a check needed its own pull request first because Mergify reads its configuration from the default branch: a pull request deleting the job would still have been gated on a check that no longer reported, and could never merge. Adding one has no such deadlock. Both pull requests here are evaluated against main's configuration, which does not name the new checks, so a single atomic commit would have merged just as well. What the split actually buys is revertability. If a new leg turns out to be red on main, reverting this commit alone unblocks the repository while keeping the coverage the previous commit added; an atomic change would have to give up both. Two consequences worth knowing, neither of which ordering can avoid. Because main's configuration does not require the new checks until this lands, nothing forces either pull request of this stack to be green on 3.13 or 3.14. Both run the full five-leg matrix on their own head, so the legs are observable, but they have to be looked at before this one is merged rather than assumed. Every pull request already open when this lands keeps the check-run set from its last CI run, and no `pull_request` event fires when the base moves. `check-success=Test with Python 3.13` can therefore never go true on it, and `auto_merge_conditions: true` folds the success conditions into the queue conditions, so it cannot enter the queue to be rebased out either. Each one needs a push, a rebase or a close/reopen to pick up the new legs. Longer term, this list is a hand-maintained mirror of the job names and will want the same ceremony at 3.15. The monorepo and mergify-cli both replaced it with one aggregate job (`all-greens` / `ci-gate`) behind a single `check-success`, which is worth adopting here on its own. Note that `check-success~=^Test with Python ` is not a shortcut for it: check-success is a list attribute and `~=` matches any element, so one green leg would satisfy it while another fails. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MKmEnjRuAM4NcTYxRXG3BA Depends-On: #310
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
2 participants
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.
Python 3.9 has been end-of-life since October 2025 and no known consumer
of sql-compare is still on it: the monorepo
engineandshadow-officeboth declare
requires-python = "~=3.14.0". Dropping it unblocksdependencies that already require 3.10, starting with sqlparse 0.6.0.
This also removes the CI workaround that existed only for 3.9. Poetry
2.4.1 needs Python >=3.10, so the job installed it under a pinned 3.12
and pointed it at the matrix interpreter with
poetry env use. With a3.10 floor a single
setup-pythonis enough. Withoutpoetry env use,though, poetry picks its interpreter off PATH, and every matrix version
satisfies
python = "^3.10"- so a wrong pick would test one versionthree times and stay green. The added assertion makes that fail loudly
instead.
[tool.ruff] target-versionis dropped so ruff infers it fromrequires-python. It said "py312" while the floor was 3.9 and wouldhave said it while the floor is 3.10; with
preview = trueandUPselected, that makes ruff raise UP040/UP046 with fixes that emit PEP 695
syntax (
type X = int,class Box[T]), which is a SyntaxError on the3.10 and 3.11 legs. Inferring keeps the two in sync permanently.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01XkWQRxh5pfi2Fbuv3Z9wen
Depends-On: #299