Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Pip 23.3.1. #2276

Merged
merged 1 commit into from
Nov 4, 2023
Merged

Add support for Pip 23.3.1. #2276

merged 1 commit into from
Nov 4, 2023

Conversation

jsirois
Copy link
Member

@jsirois jsirois commented Nov 4, 2023

This required updating the locker parsing to account for differences in
23.3.x log output.

Although 23.3 has significant changes from 23.2.x, I was away during its
release and no one clamored for it; so I'm just moving ahead to the
small 23.3.1 update. The changelogs are here:

This required updating the locker parsing to account for differences in
23.3.x log output.

Although 23.3 has significant changes from 23.2.x, I was away during its
release and no one clamored for it; so I'm just moving ahead to the
small 23.3.1 update.
@jsirois jsirois marked this pull request as ready for review November 4, 2023 19:56
@jsirois jsirois mentioned this pull request Nov 4, 2023
2 tasks
@jsirois jsirois merged commit 1f073d0 into pex-tool:main Nov 4, 2023
24 checks passed
@jsirois jsirois deleted the pip/23.3.1 branch November 4, 2023 22:09
jsirois added a commit that referenced this pull request Jun 8, 2024
When support for Pip 23.3.1 was added in #2276 a latent bug in artifact 
URL recording was exposed in cases where the index being used issued
re-directs. Fix up artifact URL recording to grab the primary index URL
and not subsequent re-directs.

Implementing the fix above led to a test failure that revealed another
bug whereby lock file artifact downloads were not respecting the locked
resolve target when it was a foreign platform, which is now fixed.

Finally, fixing the un-patched foreign platform target issue in lock 
file artifact downloads revealed that artifact URLs with hashes were not
being taken advantage of in all cases. Now, when there is a version of
an artifact URL seen that contains hashes - the best of those is always
used to prevent needless post-processing to download and hash the
artifact at lock creation time.

Fixes #2414
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants