fix(renovate): bump Python >= lower bounds on every release#343
Conversation
Root cause of mlx-benchmarks#55: `pyarrow>=17.0.0` sat untouched for months while pyarrow shipped through 18.x, 19.x, ... 24.x. The unfixable-CVE PYSEC-2026-113 (CVSS 7.0, fixed in pyarrow 23.0.1) only came to light when OSV started flagging it on every PR. Renovate's default `rangeStrategy: auto` maps to `replace` for pep621 and pip_requirements. `replace` only updates a constraint when the new version falls **outside** the existing range. Since `>=17.0.0` already satisfies pyarrow 24.0.0, replace no-ops indefinitely. The lower bound ages out of sync with the actually-installed (lockfile) version and becomes a stale security floor for downstream library consumers. The vulnerabilityAlerts block already sets `rangeStrategy: bump` for CVE-driven updates. This new packageRule mirrors that behavior for routine releases too, so: - `pyarrow>=17.0.0` becomes `pyarrow>=24.0.0` (or whatever's current) the next time pyarrow ships, without waiting for a CVE. - Library consumers installing the project as a dependency get an accurate security floor, not a years-old one. - The lockfile and pyproject specifier stay aligned. Scope: pep621, pip_requirements, pip_setup, poetry, pipenv. npm caret ranges already get bumped under `replace` because `^X.Y.Z` caps at the next major; no change needed there. Terraform `>=` constraints have the same pathology — can extend this rule if it turns up there too. Impact at the time of this PR: at minimum 18 stale `>=` pins in mlx-benchmarks, 11 in python-template, 16 in nix-ai/orchestrator, plus more across the workspace. After this lands, Renovate will open PRs to bring each of those current at the next scheduled run (Monday/Thursday mornings per the existing Python schedule rule). Assisted-by: Claude <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request updates the Renovate configuration to ensure Python dependency lower bounds are kept up-to-date. By switching the range strategy from the default 'replace' to 'bump' for specific Python managers, the system will now actively update minimum version constraints instead of ignoring them when existing ranges remain satisfied, thereby improving security and alignment with current releases. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. The version range was stuck in place, / While newer code joined in the race. / With 'bump' we now force, / A much better course, / To keep all our builds in good grace. Footnotes
|
…ce (#344) * fix(renovate): major-only Python lower-bound bumps + 30-day major grace PR #343 made `rangeStrategy: bump` apply to every release for pep621/pip_requirements/pip_setup/poetry/pipenv, so the `>=` floor moved on minor and patch releases too. That floods consumer repos with PRs that only re-state the floor at the latest pinpoint version — no security or compatibility signal behind them. Two changes: 1. 30-day grace period for any major-version update, org-wide. Gives upstream ecosystems time to surface breaking regressions before we adopt. CVE bumps still bypass via `vulnerabilityAlerts` (0 days). 2. Restrict the Python `>=` bump rule to `matchUpdateTypes: ["major"]`. Minor/patch updates now fall back to Renovate's default `replace` strategy, which no-ops when the existing range already satisfies the new version — exactly what we want for security/compatibility floors. After this, Renovate still produces `>=N.M.P` (e.g. `>=1.16.1`) on major bumps. Follow-up: a reusable normalization workflow that rewrites those to `>=N.0.0` so floors only express the major version. * docs(renovate): spell out CVE-pin exception to major-only floor policy The bump rule now states the full policy: - Default: floors are `>=N.0.0` (major only). - CVE exception: pin to the OLDEST secure version (not latest) and document every CVE in an inline comment block above the floor. - Normalizer must preserve floors preceded by such a comment block. Canonical pattern lives in mlx-benchmarks/space/requirements.txt (pyarrow, pillow, orjson, idna).
1 participant
Summary
Closes the gap that let
pyarrow>=17.0.0sit untouched for months while pyarrow shipped through 18.x → 24.x. Surfaced by mlx-benchmarks#55, where the unfixable-CVE PYSEC-2026-113 (CVSS 7.0 High, fixed in 23.0.1) only became visible when OSV started flagging it on every PR.Root cause
Renovate's default
rangeStrategy: automaps toreplaceforpep621andpip_requirements.replaceonly bumps a constraint when the new version falls outside the existing range. Since>=17.0.0is satisfied by 18, 19, 20, 21, 22, 23, and 24, replace no-ops indefinitely. The lower bound ages out of sync with the actual installed (lockfile) version and becomes a stale security floor for downstream consumers of the library.The
vulnerabilityAlertsblock already setsrangeStrategy: bumpfor CVE-driven updates. This PR mirrors that behaviour for routine releases too, on a focused set of Python managers.Change
One new packageRule appended to
renovate-presets.json:{ "matchManagers": ["pep621", "pip_requirements", "pip_setup", "poetry", "pipenv"], "rangeStrategy": "bump" }bumpforces the lower bound to track the latest release even when the existing range still satisfies it.Why this scope
bump?pep621/pip_requirements/pip_setup/poetry/pipenv>=Xranges no-op forevernpm^X.Y.Zcaps at next major; majors are outside-range soreplacebumps themcargo^X.Y.Z/~X.Y.Zbehave like npmterraform>= 1.0has the same pathologypre-commitrev:tags get exact-match bumpsImpact
At the time of this PR, every workspace repo consuming the preset has stale
>=constraints:>=pinsmlx-benchmarksnix-ai/orchestratorpython-templatenix-ai/mlx-serverclaude-code-plugins/content-guardsAfter this PR lands, Renovate will (on the next scheduled run — Mon/Thu 7am per the existing Python schedule rule) open PRs to bring each of those constraints current. Examples that are demonstrably behind today:
pyarrow>=17.0.0(fixed in mlx-benchmarks#55 to 23.0.1)pandas>=2.0psutil>=5.9pytest-cov>=5.0openai>=1.0.0mypy>=1.11huggingface-hub>=0.23pytest>=8.3pre-commit>=3.8ruff>=0.6.9Bumps will auto-merge for minor/patch (per the existing
pep621/pip_requirementsauto-merge rule) and human-review for majors (per theNever auto-merge major updatesrule already in the preset).Test plan
jq empty renovate-presets.jsonpasses>=bump PR opens against this repo or another consumer within 48hOut of scope
fix/renovate-vuln-bumpbranch (unpushed WIP that removesdependencyDashboard,osvVulnerabilityAlerts, and several settings). That refactor is broader and should be discussed separately.>=constraint bumping. Same pathology but no concrete example pinned today.🤖 Generated with Claude Code