poetry: 'pyproject.toml changed significantly since poetry.lock was generate

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: 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:

Not specified by the original author.

TL;DR

The new dependency's constraints clash with what is already locked. Read the solver message to find the conflicting pair, then widen a constraint or update the conflicting package, and run poetry lock. Do not hand-edit poetry.lock.

Error

poetry 'SolverProblemError' after adding a new dependency

Steps

1. Read the SolverProblemError output; poetry names the packages and the version bounds that cannot both hold. Expected output: You can state the clash in one sentence.

2. Check the python constraint too: a narrow python = "3.9" style bound in pyproject.toml rules out many new releases. Expected output: You know whether python itself is part of the conflict.

3. Fix one side: poetry add [package] with a looser constraint, or poetry update [conflicting package] to a version compatible with the newcomer. Expected output: The constraints admit a common solution.

4. Regenerate the lockfile: poetry lock, then review git diff poetry.lock for unexpected moves. Expected output: The lockfile resolves cleanly and the diff is scoped to the change.

5. Install and test: poetry install, then run the suite. Expected output: The environment builds and tests pass.

When to use

• poetry add fails with SolverProblemError
• A new dependency's requirements clash with the locked set
• The python version bound in pyproject.toml blocks the solve

When not to use

• CI fails on a stale lockfile message; that is lockfile drift, not a solver failure
• The install step fails downloading; that is network, not resolution
• You want to change many versions at once; use poetry update deliberately instead

Variant phrasings

poetry add fails with SolverProblemError naming two packages

The classic shape: the newcomer and one locked package disagree on a shared transitive dep.

SolverProblemError after widening the python constraint

Widening python can expose new conflicts; the solver message names the next clash.

poetry lock fails the same way poetry add did

The lock step re-solves from scratch; fix the constraints, not the lockfile.

Why it happens

Poetry solves the full graph including the python constraint before writing the lockfile. Adding a package introduces its bounds on shared transitive dependencies, and if those bounds exclude every version compatible with the rest of the lock, the solver reports the dead end instead of guessing.

Edge cases

• poetry update without arguments re-resolves everything and can move many versions; prefer poetry update [package].
• The solver respects the python constraint strictly; a package requiring 3.10 will never solve under python = "3.9".
• If the solver is slow rather than failing, the constraint set is huge; narrowing the search with tighter pins helps.

Provenance

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

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

Thread query: poetry 'SolverProblemError' after adding a new dependency

TL;DR: The new dependency's constraints clash with what is already locked. Read the solver message to find the conflicting pair, then widen a constraint or update the conflicting package, and run poetry lock. Do not hand-edit poetry.lock.