chore(deps): regenerate requirements-build.lock for hatchling 1.31.0 - #228
Merged
Conversation
The build lock pinned hatchling 1.30.1; 1.31.0 has since been released. `build-system.requires` is unpinned (`["hatchling"]`), so CI's drift check recompiles it, resolves the new version, and diffs against the committed lock — which now fails on every PR against main, regardless of content. PR #227 is simply the next one opened. Regenerated with the command the check itself prints. Wheel builds clean on 1.31.0 (kayak-1.2.0-py3-none-any.whl), and the recompile is now a no-op. This recurs by construction: an unpinned requirement plus a hashed lock means each hatchling release reds the repo until someone regenerates. Worth either letting Dependabot own this file or pinning the requires floor — out of scope here, where the goal is just to unblock. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RR6LwVdry9fmXkEhkC9Cbi
mousebrains
added a commit
that referenced
this pull request
Jul 15, 2026
Fixes uv.lock rot. Python was the one ecosystem here nothing watched, and it shows: 19 packages behind (mypy 2.1→2.3, ruff 0.15.18→0.15.21, numpy 2.4.6→2.5.1, …), noticed only because CI went red for an unrelated reason. This is NOT the fix for #228 and does not stop it recurring. #228 was `requirements-build.lock`, which is `uv pip compile`d from the *unpinned* `[build-system].requires` and re-resolved against live PyPI on every CI run — so the next hatchling release reds every open PR again, exactly as before. The `uv` ecosystem reads `[project]` deps + uv.lock and never touches `[build-system].requires`; no ecosystem scans that file at all. Pinning a floor (`requires = ["hatchling>=1.27,<2"]`) is what retires that, and it is a separate change. Saying otherwise here would send the next person to hit a red build-lock check hunting for a new bug instead of a known one. The omission being reversed was deliberate and correctly reasoned when written — Dependabot couldn't update uv.lock. That stopped being true when uv version updates went GA on 2025-03-13. Stale premise, not a judgment call. Monthly + grouped like the other three: one Python PR a month. Known rough edge, documented in the file rather than left to be discovered: Dependabot rewrites uv.lock but not requirements-prod.lock, which CI diffs against a fresh `uv export`, so a grouped PR bumping any runtime dep lands red until someone regenerates it on the branch — six of the current nineteen qualify. The sharper reason not to let that sit is that pip-audit reads requirements-prod.lock, not uv.lock: until the export is regenerated, a security bump to a runtime dep isn't actually being audited. Automating it away is not cheap either — Dependabot-triggered workflows get a read-only GITHUB_TOKEN, so pushing the export back needs pull_request_target or a PAT. The manual export is the sane option, not a stopgap. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RR6LwVdry9fmXkEhkC9Cbi
mousebrains
added a commit
that referenced
this pull request
Jul 15, 2026
) This is what actually retires #228. `[build-system].requires` was unbounded, requirements-build.lock is `uv pip compile`d from it, and CI's drift check recompiles against live PyPI every run and diffs — so hatchling 1.31.0 shipping reddened every open PR, whatever its diff. #228 regenerated the lock by hand; that bought time, it didn't fix anything. A range does not fix it either, which is worth stating because it is the obvious reach: `uv pip compile` resolves the NEWEST version a specifier admits, so `>=1.27,<2` re-resolves the day 1.32.0 lands and the lock is stale again. Measured, not assumed: hatchling>=1.27,<2 -> 1.31.0 (newest in range — drifts again) hatchling>=1.27,<1.31 -> 1.30.1 (proves it takes the max, not a pin) hatchling==1.30.1 -> 1.30.1 (stable) Only `==` makes compile-then-diff idempotent, which is the property the check needs. It also fits what this feeds: kayak-deploy builds the wheel with --no-build-isolation from the hashed lock (#190), so the backend version is part of the artifact and pinning it is the point, not a wart. The cost is that nothing watches this line — no Dependabot ecosystem reads [build-system].requires, so hatchling now goes stale until bumped by hand. A stale-but-working build backend is a strictly better failure than an unpredictable red CI, and the comment carries the two-line bump recipe. Lock unchanged: #228 already put 1.31.0 there, so this only removes the mechanism that made that a recurring chore. Drift check verified idempotent across repeated runs; wheel builds clean. Claude-Session: https://claude.ai/code/session_01RR6LwVdry9fmXkEhkC9Cbi Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mousebrains
added a commit
that referenced
this pull request
Jul 15, 2026
Fixes uv.lock rot. Python was the one ecosystem here nothing watched, and it shows: 19 packages behind (mypy 2.1→2.3, ruff 0.15.18→0.15.21, numpy 2.4.6→2.5.1, …), noticed only because CI went red for an unrelated reason. This is NOT the fix for #228 and does not stop it recurring. #228 was `requirements-build.lock`, which is `uv pip compile`d from the *unpinned* `[build-system].requires` and re-resolved against live PyPI on every CI run — so the next hatchling release reds every open PR again, exactly as before. The `uv` ecosystem reads `[project]` deps + uv.lock and never touches `[build-system].requires`; no ecosystem scans that file at all. Pinning a floor (`requires = ["hatchling>=1.27,<2"]`) is what retires that, and it is a separate change. Saying otherwise here would send the next person to hit a red build-lock check hunting for a new bug instead of a known one. The omission being reversed was deliberate and correctly reasoned when written — Dependabot couldn't update uv.lock. That stopped being true when uv version updates went GA on 2025-03-13. Stale premise, not a judgment call. Monthly + grouped like the other three: one Python PR a month. Known rough edge, documented in the file rather than left to be discovered: Dependabot rewrites uv.lock but not requirements-prod.lock, which CI diffs against a fresh `uv export`, so a grouped PR bumping any runtime dep lands red until someone regenerates it on the branch — six of the current nineteen qualify. The sharper reason not to let that sit is that pip-audit reads requirements-prod.lock, not uv.lock: until the export is regenerated, a security bump to a runtime dep isn't actually being audited. Automating it away is not cheap either — Dependabot-triggered workflows get a read-only GITHUB_TOKEN, so pushing the export back needs pull_request_target or a PAT. The manual export is the sane option, not a stopgap. Claude-Session: https://claude.ai/code/session_01RR6LwVdry9fmXkEhkC9Cbi Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Unblocks CI on every open PR, including #227.
What broke
requirements-build.lockpinshatchling==1.30.1. 1.31.0 has since been released. Becausepyproject.toml's[build-system].requiresis unpinned (["hatchling"]), the requirements-build.lock drift check recompiles it, resolves 1.31.0, and diffs against the committed lock:That fails
test (3.13)andtest (3.14)on any PR against main, whatever it changes. #227 is red purely because it was the next one opened — its diff touches no packaging file at all. main itself last ran green on 2026-07-01, before 1.31.0 existed.Fix
Regenerated with the exact command the check prints on failure. The recompile is now a no-op, and the wheel builds clean on 1.31.0 (
kayak-1.2.0-py3-none-any.whl).Note for later (not in scope here)
This recurs by construction: an unpinned
requiresplus a hashed lock means every hatchling release reds the repo until a human regenerates. Two ways out — let Dependabot ownrequirements-build.lock, or pin a floor in[build-system].requiresso the resolve is stable. Happy to do either as a follow-up; this PR just unblocks.— Claude · Opus-4.8(1M) · x-high