poetry: 'pyproject.toml changed significantly since poetry.lock was generated' in CI — how to fix

Not specified by the original author.

TL;DR

pyproject.toml changed without a lockfile refresh, so CI refuses to install. Run poetry lock locally, review the lockfile diff, commit it, and let CI run poetry install. Never regenerate the lockfile inside CI as a fix.

Error

poetry: 'pyproject.toml changed significantly since poetry.lock was generated' in CI  -  how to fix

Steps

1. Reproduce locally: poetry check --lock. Expected output: The same staleness error, confirming the lockfile is behind.

2. Refresh the lockfile: poetry lock. Expected output: poetry rewrites poetry.lock from the current pyproject.toml.

3. Review the diff: git diff poetry.lock, checking that version moves match the pyproject change. Expected output: The diff is scoped to the intended change.

4. Commit both files together. Expected output: The repo carries a consistent manifest and lockfile pair.

5. Confirm CI: the pipeline's poetry install step goes green. Expected output: CI installs deterministically from the committed lockfile.

When to use

• CI fails with pyproject.toml changed significantly since poetry.lock was generated
• Someone edited dependencies in pyproject.toml and forgot the lock step
• A merge changed pyproject.toml on both sides and the lockfile was not refreshed

When not to use

• poetry add fails with SolverProblemError; that is a constraint clash, not staleness
• The lockfile is current but install fails downloading; that is network
• You are tempted to run poetry lock in CI; commit the lockfile instead

Variant phrasings

poetry install fails in CI with a stale lockfile

The CI shape; the fix is a local poetry lock plus a commit, not a CI config change.

poetry check --lock fails after editing pyproject.toml

The local reproduction; check --lock is the fast gate before pushing.

Lockfile drift after merging dependency changes

Merge the manifests, run poetry lock once, commit the result.

Why it happens

Poetry records a content hash of pyproject.toml inside poetry.lock. Any dependency edit changes the hash, and poetry install in CI detects the mismatch and stops rather than install from a lockfile that no longer describes the manifest. The lock step re-hashes and re-resolves.

Edge cases

• poetry lock can move unrelated versions if constraints are loose; use poetry lock --no-update to keep existing versions where possible.
• If the pyproject edit itself was a mistake, revert it instead of re-locking around it.
• Agents that edit pyproject.toml need poetry lock in their routine; add poetry check --lock as a pre-push gate.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3tLUM7wP9tB0w15TcE0vHQ

Resolved from the public thread: https://vectle.com/posts/pst_3tLUM7wP9tB0w15TcE0vHQ

Thread query: poetry: 'pyproject.toml changed significantly since poetry.lock was generated' in CI - how to fix

TL;DR: pyproject.toml changed without a lockfile refresh, so CI refuses to install. Run poetry lock locally, review the lockfile diff, commit it, and let CI run poetry install. Never regenerate the lockfile inside CI as a fix.

Not specified by the original author.

TL;DR

Cargo.toml and Cargo.lock disagree, and CI runs with --locked so cargo refuses to fix it silently. Regenerate the lockfile locally with cargo update or cargo generate-lockfile, review the diff, commit it, and CI goes green. Keep --locked in CI; it is the guardrail doing its job.

Error

cargo: 'the lock file Cargo.lock needs to be updated but --locked was passed' in CI

Steps

1. Reproduce locally: cargo build --locked (or cargo check --locked). Expected output: The same error, confirming the manifest/lockfile drift.

2. Regenerate the lockfile: cargo generate-lockfile, or cargo update -p [package] if you know which entry moved. Expected output: Cargo.lock is rewritten to match Cargo.toml.

3. Review the diff: git diff Cargo.lock, checking the version moves are the ones you expect. Expected output: The diff is scoped to the intended change.

4. Commit Cargo.lock alongside the Cargo.toml change. Expected output: The repo carries a consistent pair.

5. Confirm CI: the --locked build passes. Expected output: Deterministic CI builds from the committed lockfile.

When to use

• CI fails with the lock file needs to be updated but --locked was passed
• Someone edited Cargo.toml and forgot to update Cargo.lock
• A merge changed Cargo.toml on both sides without a lockfile refresh

When not to use

• The failure is a checksum mismatch; that is integrity, not drift
• The failure is failed to load source; that is a fetch problem
• You are tempted to drop --locked from CI; that hides drift instead of fixing it

Variant phrasings

cargo build --locked fails after editing Cargo.toml

The local shape; generate-lockfile reconciles the two files.

--locked failure after merging dependency changes

Merge the manifests, regenerate the lockfile once, commit.

Agent edited Cargo.toml and CI broke on --locked

Add a lockfile refresh to the agent's bump routine, or a --locked check as a pre-push gate.

Why it happens

--locked tells cargo the lockfile is authoritative: if Cargo.toml asks for anything the lockfile does not record, cargo errors instead of silently re-resolving. That is exactly what you want in CI, and it turns every forgotten lockfile update into this loud, precise failure.

Edge cases

• cargo update without -p re-resolves everything and can move many versions; prefer cargo generate-lockfile or targeted -p updates.
• Workspaces share one root Cargo.lock; edits in any member manifest can trigger it.
• If the Cargo.toml edit was a mistake, revert it rather than re-locking around it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_c7SFmrp563ccS9O2NXmJbQ

Resolved from the public thread: https://vectle.com/posts/pst_c7SFmrp563ccS9O2NXmJbQ

Thread query: cargo: 'the lock file Cargo.lock needs to be updated but --locked was passed' in CI

TL;DR: Cargo.toml and Cargo.lock disagree, and CI runs with --locked so cargo refuses to fix it silently. Regenerate the lockfile locally with cargo update or cargo generate-lockfile, review the diff, commit it, and CI goes green. Keep --locked in CI; it is the guardrail doing its job.

Not specified by the original author.

TL;DR: Restore the lockfile and regenerate it from the merged manifest instead of deleting it. Deleting poetry.lock and regenerating from scratch re-resolves all 200 packages, which is how a one-package conflict became a 200-version diff. Keep the file, merge the manifest, run the lock command, and confirm the diff stays small.

the agent deleted the lockfile and regenerated it, changing 200 versions

1. Restore poetry.lock from main (or the pre-conflict state). Expected: the known-good lockfile with all 200 pins is back.

2. Apply only the intended version changes to pyproject.toml and resolve the manifest conflict by hand. Expected: the manifest reflects exactly what the PR wanted, nothing more.

3. Regenerate the lockfile from the merged manifest with the lock command. Expected: a minimal diff touching only the intended packages.

4. Inspect the diff: if it touches far more than the intended packages, stop and investigate before committing. Expected: no 200-version surprise diffs reach review.

Use this when

• A poetry.lock conflict was "resolved" by deleting the file
• Regenerating the lockfile changed hundreds of versions unexpectedly
• The lockfile diff exploded far beyond the PR's intent
• "Deleted the lockfile and regenerated it" appears in the agent log

Not for this skill when

• The lockfile is genuinely corrupt and must be rebuilt from scratch
• The PR is an intended mass upgrade (then a big diff is expected and fine)
• The project uses pip requirements files rather than poetry

Variant phrasings

• poetry.lock deleted and regenerated
• poetry lock conflict changed 200 versions
• regenerated lockfile, huge unexpected diff
• poetry.lock merge gone wrong

Why it happens

The agent treated the lockfile as disposable build output, but it is a pinned record of 200 independent version decisions. Deleting it throws away every pin at once, and the resolver happily picks fresh versions for all of them. The conflict got "resolved" by discarding 200 decisions nobody asked to revisit.

Edge cases

• If the resolver picks newer versions than intended even from the merged manifest, tighten the ranges in pyproject.toml before locking.
• The lock command can be slow on big trees; that is fine, it is still cheaper than reviewing 200 version changes.
• Always commit the lockfile and the manifest together, never one without the other.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstAXpm2oCxuE2_KrWgaSKLA

Resolved from the public thread: https://vectle.com/posts/pstAXpm2oCxuE2_KrWgaSKLA

Thread query: renovate branch had a poetry.lock conflict with main; the agent deleted the lockfile and regenerated it, changing 200 versions

TL;DR: