fix(deps): manage bot lockfile with Renovate pip-compile manager (#178) #179
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/178-pydantic-lock-pip-compile"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #178.
Why
bot/requirements.txtis a pip-compile lockfile (sourcebot/requirements.in). Its only direct pydantic dependency ispydantic-settings;pydanticandpydantic-coreare transitive, and pydantic pins pydantic-core to an exact version.Renovate managed this file with the
pip_requirementsmanager, which edits pins in place, one package per PR, never re-running pip-compile. Every pydantic bump therefore decoupled the pair:…failing the bot tests, the dependency audit, and the bot Docker image build. The mirror PR (
pydantic-core → 2.47.0) was unmergeable by construction — pydantic 2.13.4 pins core to exactly 2.46.4.mainwas never broken (2.12.5 + 2.41.5 are internally consistent) — only the Renovate branches were. But this would have recurred on every future pydantic bump, including security bumps.What changed
renovate.json— optbot/requirements.txtinto thepip-compilemanager (its defaultmanagerFilePatternsis empty, so it requires explicit opt-in), and disablepip_requirementsfor that one file only.bot/requirements.txt— regenerated to a consistent pair:pydantic 2.12.5 → 2.13.4,pydantic-core 2.41.5 → 2.46.4. The regen also corrected pre-existing drift: addspyjwt==2.13.0(required byredis==5.3.1, previously missing) and drops a stalesniffioentry.Deliberately out of scope
webapp/backend/requirements.txtstays onpip_requirements. Despite a header claimingpip-compile requirements.in, there is nowebapp/backend/requirements.inin the repo — it's hand-maintained and doesn't pinpydantic/pydantic-coreat all, so it never hit this conflict. That misleading header is worth a separate tidy-up.Verification
Installed the regenerated lock in
python:3.12and ran the suite:ResolutionImpossible)pydantic 2.13.4+pydantic-core 2.46.4confirmed installedrenovate-config-validator(renovate 42.99.0) — "Config validated successfully" as repo configCI on this PR re-validates the bot image build that was failing.
Follow-ups
pydantic → 2.13.4,pydantic-core → 2.47.0) — they should be closed once this merges.pip-compilemanager must be able to execute pip-compile (Python 3.12 + pip-tools) in the Renovate runner. Renovate runs from an external/central runner, not a workflow in this repo — worth confirming on the next run that it regenerates the lock rather than erroring on artifact update.🤖 Generated with Claude Code
bot/requirements.txt is a pip-compile lockfile whose only direct pydantic dependency is pydantic-settings; pydantic and pydantic-core are transitive, and pydantic pins pydantic-core to an exact version. Renovate managed the file with the pip_requirements manager, which edits pins in place one package per PR and never re-runs pip-compile, so each pydantic bump decoupled the pair: The user requested pydantic-core==2.41.5 pydantic 2.13.4 depends on pydantic-core==2.46.4 ...failing bot tests, the dependency audit, and the bot image build. The mirror PR (pydantic-core 2.47.0) was unmergeable by construction. main itself was never broken; only the Renovate branches were. Opt bot/requirements.txt into the pip-compile manager (empty default managerFilePatterns, so it needs explicit opt-in) and disable pip_requirements for that one file, leaving webapp/backend/requirements.txt and the requirements-dev.txt files untouched — webapp has no requirements.in and is hand-maintained. Regenerate the lock to a consistent pair: pydantic 2.13.4 + pydantic-core 2.46.4. This also corrects pre-existing drift (adds pyjwt, required by redis 5.3.1; drops a stale sniffio entry). Verified in python:3.12: installs cleanly, 186 bot tests pass. Config validated by renovate-config-validator (renovate 42.99.0). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>