[Deps] Renovate decouples pydantic from pydantic-core in the compiled bot lockfile (ResolutionImpossible) #178

New issue

Closed

opened 2026-07-16 21:28:05 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-16 21:28:05 +00:00

Contributor

Problem

Every Renovate pydantic PR fails CI (bot tests, dependency audit, and the bot Docker image build) with ResolutionImpossible:

ERROR: Cannot install -r requirements.txt (line 56) and pydantic-core==2.41.5
because these package versions have conflicting dependencies.
The conflict is caused by:
    The user requested pydantic-core==2.41.5
    pydantic 2.13.4 depends on pydantic-core==2.46.4

Root cause

bot/requirements.txt is a genuine pip-compile lockfile (source: bot/requirements.in). The only direct dependency is pydantic-settings>=2.3.0; pydantic and pydantic-core are transitive, and pydantic pins pydantic-core to an exact version:

pydantic==2.12.5        # via pydantic-settings
pydantic-core==2.41.5   # via pydantic  <- pydantic 2.12.5 requires exactly this

Renovate was managing this file with the pip_requirements manager, which edits pins in place, one package per PR, and never re-runs pip-compile. So:

"pydantic → 2.13.4" bumps only that line → pydantic now demands pydantic-core==2.46.4 while the file still says 2.41.5 → unresolvable.
"pydantic-core → 2.47.0" is the mirror image, and was never mergeable by construction: pydantic 2.13.4 pins core to exactly 2.46.4, so 2.47.0 belongs to a newer pydantic that nothing requests.

This affects every future pydantic bump, including security bumps — not a one-off.

main itself was never broken (2.12.5 + 2.41.5 are internally consistent); only the Renovate branches were.

Fix

Manage bot/requirements.txt with Renovate's pip-compile manager, so an update regenerates the whole lock and moves pydantic + pydantic-core together. The manager has an empty default managerFilePatterns, so it must be opted in explicitly, and the overlapping pip_requirements manager is disabled for that one file only.
Regenerate the lock to a consistent pair: pydantic 2.12.5 → 2.13.4, pydantic-core 2.41.5 → 2.46.4.

Scope note

webapp/backend/requirements.txt is not affected and intentionally stays on pip_requirements: despite a header claiming pip-compile requirements.in, there is no webapp/backend/requirements.in in the repo — it's hand-maintained and doesn't pin pydantic/pydantic-core at all. (That stale/misleading header is worth a separate tidy-up.)

The regen also corrected pre-existing lock drift: pyjwt==2.13.0 was missing though redis==5.3.1 requires it, and a stale sniffio entry was dropped.

Verification

Installed the regenerated lock in python:3.12 and ran the bot suite:

resolves/installs cleanly (previously ResolutionImpossible)
pydantic 2.13.4 + pydantic-core 2.46.4 confirmed installed
186 bot tests pass
renovate-config-validator (renovate 42.99.0) validates the config as repo config

Runner prerequisite

The pip-compile manager must be able to execute pip-compile (Python 3.12 + pip-tools) in the Renovate runner environment. Renovate runs from an external/central runner, not a workflow in this repo — if it can't run pip-compile, it will report an artifact-update error instead of silently producing a broken PR. Worth confirming on the next Renovate run.

## Problem Every Renovate pydantic PR fails CI (bot tests, dependency audit, and the bot Docker image build) with `ResolutionImpossible`: ``` ERROR: Cannot install -r requirements.txt (line 56) and pydantic-core==2.41.5 because these package versions have conflicting dependencies. The conflict is caused by: The user requested pydantic-core==2.41.5 pydantic 2.13.4 depends on pydantic-core==2.46.4 ``` ## Root cause `bot/requirements.txt` is a genuine **pip-compile lockfile** (source: `bot/requirements.in`). The only *direct* dependency is `pydantic-settings>=2.3.0`; **`pydantic` and `pydantic-core` are transitive**, and pydantic pins pydantic-core to an **exact** version: ``` pydantic==2.12.5 # via pydantic-settings pydantic-core==2.41.5 # via pydantic <- pydantic 2.12.5 requires exactly this ``` Renovate was managing this file with the **`pip_requirements`** manager, which edits pins **in place, one package per PR**, and never re-runs pip-compile. So: - *"pydantic → 2.13.4"* bumps only that line → pydantic now demands `pydantic-core==2.46.4` while the file still says `2.41.5` → unresolvable. - *"pydantic-core → 2.47.0"* is the mirror image, and was never mergeable by construction: pydantic 2.13.4 pins core to exactly `2.46.4`, so `2.47.0` belongs to a newer pydantic that nothing requests. This affects **every** future pydantic bump, including security bumps — not a one-off. `main` itself was never broken (2.12.5 + 2.41.5 are internally consistent); only the Renovate branches were. ## Fix 1. **Manage `bot/requirements.txt` with Renovate's `pip-compile` manager**, so an update regenerates the whole lock and moves pydantic + pydantic-core together. The manager has an empty default `managerFilePatterns`, so it must be opted in explicitly, and the overlapping `pip_requirements` manager is disabled **for that one file only**. 2. **Regenerate the lock** to a consistent pair: `pydantic 2.12.5 → 2.13.4`, `pydantic-core 2.41.5 → 2.46.4`. ### Scope note `webapp/backend/requirements.txt` is **not** affected and intentionally stays on `pip_requirements`: despite a header claiming `pip-compile requirements.in`, there is **no `webapp/backend/requirements.in` in the repo** — it's hand-maintained and doesn't pin `pydantic`/`pydantic-core` at all. (That stale/misleading header is worth a separate tidy-up.) The regen also corrected pre-existing lock drift: `pyjwt==2.13.0` was missing though `redis==5.3.1` requires it, and a stale `sniffio` entry was dropped. ## Verification Installed the regenerated lock in `python:3.12` and ran the bot suite: - resolves/installs cleanly (previously `ResolutionImpossible`) - `pydantic 2.13.4` + `pydantic-core 2.46.4` confirmed installed - **186 bot tests pass** - `renovate-config-validator` (renovate 42.99.0) validates the config as repo config ## Runner prerequisite The `pip-compile` manager must be able to **execute pip-compile** (Python 3.12 + pip-tools) in the Renovate runner environment. Renovate runs from an external/central runner, not a workflow in this repo — if it can't run pip-compile, it will report an artifact-update error instead of silently producing a broken PR. Worth confirming on the next Renovate run.