Reconcile PEP 658 sidecar metadata with the downloaded wheel#13991
Open
dewankpant wants to merge 1 commit into
Open
Reconcile PEP 658 sidecar metadata with the downloaded wheel#13991dewankpant wants to merge 1 commit into
dewankpant wants to merge 1 commit into
Conversation
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
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.
Refs #13983.
Summary
This adds a post-download consistency check between PEP 658 sidecar metadata and the embedded
METADATAof the downloaded wheel.PEP 658 metadata can be used by pip during dependency resolution before the wheel itself is downloaded. Once the wheel is available locally, pip now checks that the resolver-affecting fields from the sidecar-derived distribution match the canonical metadata embedded in the wheel. If
Requires-Dist,Requires-Python, orProvides-Extradiffer, pip raisesMetadataInconsistentand aborts the install. If either side contains an unparseableRequires-Distentry, pip raisesMetadataInvalid, matching the existing metadata validation pattern.This is the hardening improvement discussed in #13983. It does not change pip's threat model, but it does enforce the expectation that PEP 658 metadata used for resolution remains consistent with the downloaded artifact's canonical metadata.
Scope
_canonicalize_requirementand_reconcile_metadata_against_wheelhelpers insrc/pip/_internal/operations/prepare.py.metadata_link.FakePackagetest fixture to emit one metadata header perRequires-Dist/Provides-Extraentry.Requires-Dist,Requires-Python,Provides-Extra, canonicalization tolerance, and invalid requirement metadata.Requires-Distmismatch path using the existingdownload_local_html_indexfixture.Test plan
pre-commit runon all touched files: all hooks green.pytest tests/unit/test_operations_prepare.py -q --no-cov: 10 passed.pytest tests/functional/test_download.py -k "metadata or canonicalizes or mismatch" -q --no-cov: 15 passed.Requires-Distentry not present in the wheel metadata. Patched pip rejects the install withhas inconsistent Requires-Dist.I also ran the broader functional matrix:
pytest tests/functional/test_download.py tests/functional/test_install.py tests/functional/test_new_resolver.py -q --no-cov -p no:cacheproviderThis produced
321 passed, 2 failed, 5 skipped, 1 xfailed, 2 xpassed.The two failed cases were:
tests/functional/test_install.py::test_pep518_with_user_piptests/functional/test_install.py::test_install_existing_memory_distributionI reproduced both of the above on a clean
origin/mainworktree atf7bfe280f, so they are unrelated to this PR's PEP 658 metadata reconciliation path.