fix(update): re-lock all Pipfile entries when no packages are given (#6672)#6675
Merged
Merged
Conversation
…6672) `docs/commands.md` describes `pipenv update` (no args) as `lock + sync`, but since gh-6455 (released in 2026.0.0) it routed through `upgrade()` which only re-resolves Pipfile entries whose locked version no longer satisfies the Pipfile spec. Relaxing a pin (the bug reporter's case: `urllib3 = "<2.7.0"` -> `urllib3 = "*"`) leaves the lockfile pinned to the existing version because that version still satisfies the new spec, so `pipenv update` becomes a no-op. Route `do_update` through `do_lock` when no packages/editables are given, scoped to the same categories `_prepare_categories` would have selected for the upgrade path (default + develop when --dev, default otherwise). The targeted `pipenv update <pkg>` flow keeps the existing `upgrade()` path. Verified end-to-end against the issue's reproducer: with the fix, relaxing `urllib3 = "<2.7.0"` -> `urllib3 = "*"` re-locks 2.6.3 -> 2.7.0 as expected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pipenv updatedoes not lock anymore #6672. Since 2026.0.0,pipenv update(no args) silently became a no-op when relaxing a Pipfile pin — the lockfile stayed at the previously pinned version even when the spec allowed newer releases.do_updatethrough the partialupgrade()path, which only re-resolves Pipfile entries whose locked version no longer satisfies the spec. Relaxingurllib3 = "<2.7.0"→urllib3 = "*"doesn't trigger that condition because2.6.3still satisfies*.docs/commands.md:241describespipenv update(no args) aslock + sync. This PR restores that semantics by routingdo_updatethroughdo_lockwhen no packages/editables are given, scoped to the same categories_prepare_categorieswould pick (default + develop on--dev, default otherwise). The targetedpipenv update <pkg>flow is unchanged.Test plan
tests/unit/test_update.pycovering: no-args routes throughdo_lock;<pkg>routes throughupgrade;--devlocks default + develop; default locks default only;--outdatedstill bypasses both paths.tests/unit/test_update.pytests still pass (16/16).urllib3 = "<2.7.0"locked at2.6.3, then changed tourllib3 = "*"and ranpipenv update— lockfile re-resolved tourllib3==2.7.0.🤖 Generated with Claude Code