Transient resolver hash mismatch error

[ofek]

Description

Rerunning the two macOS jobs made the error go away: https://github.com/pypa/hatch/actions/runs/8674531141/job/23786948248?pr=1384#step:6:17

As you can see from:

• https://github.com/pypa/hatch/blob/792cb4763b1e99f5b7b55837ca08d5a2ac4450bd/src/hatch/env/internal/static_analysis.py#L17
• https://github.com/pypa/hatch/blob/792cb4763b1e99f5b7b55837ca08d5a2ac4450bd/src/hatch/env/plugin/interface.py#L899

The command that's happening is essentially:

pip install ruff==0.3.5

Expected behavior

No response

pip version

24.0

Python version

3.9, 3.10

OS

macOS

How to Reproduce

Unknown

Output

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[ofek]

Some links:

• https://pypi.org/project/ruff/0.3.5/#files - one of the hashes appears to be from the ruff-0.3.5-py3-none-macosx_10_12_x86_64.whl artifact but I don't know where the other one might be coming from
• GitHub runner pip version documented here: https://github.com/actions/runner-images/blob/main/images/macos/macos-12-Readme.md#package-management

[pfmoore]

One pip probably tried to read a partially-downloaded file from the cache. Pip doesn't protect against concurrent access - see #2361.

[ofek]

That would surprise me because Hatch doesn't run pip in parallel

[pfmoore]

Sorry, maybe I misunderstood. Because you mentioned "two MacOS jobs", I assumed they were running independently and both executing pip. If it's not that, then I don't know what else it could be, and we'll probably need a reproducer to identify the problem.

[ofek]

Yeah two separate VMs failed at the same step/dependency and at the same time, I don't know how to reproduce

[sbidoul]

Might be related to #11153

[ofek]

Ah, that sounds exactly like the issue indeed. How hard would an upgrade to urllib3 be? 😅

[notatallshaw]

How hard would an upgrade to urllib3 be? 😅

#12026 (comment)

[ofek]

Okay I guess this is blocked until next year; feel free to close if that's how the process works!