You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pip cache has old version of http cache on Windows+pypy #972
I don't know. It happens sometimes and not other times, it goes away after a while.
Expected behavior:
pip install using the cache works fine.
Actual behavior:
It doesn't.
I tried debugging this a bit. See the commits on python-trio/trio#3118 and specifically the actions runs and their logs. I copied relevant outputs to comments.
Firstly, this bug manifests in that pip thinks uv==0.4.17 does not exist. Inspecting the http cache file pip is using for its request to pypi.org/simple/uv, I note that it differs between a successful run (CPython 3.8 on Windows) and an unsuccessful run (PyPy-3.10 on Windows). Specifically, I note that the cached file CPython finds is up to date having up to uv==0.4.25 listed, but the cached file PyPy finds is old with the latest version being uv==0.4.8.
I don't understand how the cached http file can be varied between two different versions.
Maybe this helps: for some reason, the hash of the requirements file differs between the two runs. Obviously this doesn't make sense.
Could you kindly provide the steps to reproduce the issue? I am currently unable to replicate it. The setup-python commit you are referring to contains test files and does not include any changes to the setup-python cache code.
Could you kindly provide the steps to reproduce the issue? I am currently unable to replicate it. The setup-python commit you are referring to contains test files and does not include any changes to the setup-python cache code.
Hi,
Unfortunately I don't know how to reproduce this. Note that similar happenings happened in python-pillow/Pillow#8514 so it's not just our setup.
I am currently unable to replicate the issue you mentioned. I have tested the workflow on a Windows hosted runner with pypy-3.10, and it appears to be working fine as shown in the attached screenshot.
Please ensure that your workflow configuration is correct and matches the expected format. If the issue persists, it might be helpful to provide more details about your specific setup or any error messages you are encountering.
I have tested the workflow on a Windows hosted runner with pypy-3.10, and it appears to be working fine as shown in the attached screenshot.
This is expected, it very much has to do with what's in cache. I'm honestly not sure if setup-python is the culprit here. It appears that there's an incorrect file in the cachedir pip uses, for some reason.
Given that if I delete caches this problem disappears it makes sense you can't reproduce without those caches. However, it's notable this has happened to 2 projects with (probably) different CI setups. I'll go ahead and confirm whether its actually a cache issue (which would be apparant if we have disagreeing cached bodies and headers -- I think we do) and report back with findings.
OK I'm pretty sure this is a pip issue. Here's the files in the http-v2 cache:
-rw-r--r-- 1 runneradmin 197121 1819 Nov 9 06:29 c:/users/runneradmin/appdata/local/pip/cache/http-v2/a/d/e/e/f/adeef5b9611702687bbddade5f7c0af65110caf98ba1a0070c9d116e
-rw-r--r-- 1 runneradmin 197121 228583 Oct 28 14:08 c:/users/runneradmin/appdata/local/pip/cache/http-v2/a/d/e/e/f/adeef5b9611702687bbddade5f7c0af65110caf98ba1a0070c9d116e.body
-rw-r--r-- 1 runneradmin 197121 238531 Nov 9 06:29 c:/users/runneradmin/appdata/local/pip/cache/http-v2/a/d/e/e/f/adeef5b9611702687bbddade5f7c0af65110caf98ba1a0070c9d116e.body4f_dkhwx.tmp
-rw-r--r-- 1 runneradmin 197121 232580 Nov 1 01:08 c:/users/runneradmin/appdata/local/pip/cache/http-v2/a/d/e/e/f/adeef5b9611702687bbddade5f7c0af65110caf98ba1a0070c9d116e.body9k42hbh3.tmp
-rw-r--r-- 1 runneradmin 197121 234523 Nov 5 22:53 c:/users/runneradmin/appdata/local/pip/cache/http-v2/a/d/e/e/f/adeef5b9611702687bbddade5f7c0af65110caf98ba1a0070c9d116e.bodyd4lemxfj.tmp
for some reason pip isn't able to replace the tmpfile and yet it suppresses that error. I'll close this issue cause this issue is not related to this action.
Activity
v-priya-kinthali commentedon Oct 28, 2024
Hello @A5rocks 👋,
Thank you for reporting this issue. We will investigate it and get back to you as soon as we have some feedback.
v-mahabaleshwars commentedon Nov 5, 2024
Hello @A5rocks,
Could you kindly provide the steps to reproduce the issue? I am currently unable to replicate it. The setup-python commit you are referring to contains test files and does not include any changes to the setup-python cache code.
A5rocks commentedon Nov 5, 2024
Hi,
Unfortunately I don't know how to reproduce this. Note that similar happenings happened in python-pillow/Pillow#8514 so it's not just our setup.
v-mahabaleshwars commentedon Nov 7, 2024
Hello @A5rocks,
I am currently unable to replicate the issue you mentioned. I have tested the workflow on a Windows hosted runner with pypy-3.10, and it appears to be working fine as shown in the attached screenshot.
Please ensure that your workflow configuration is correct and matches the expected format. If the issue persists, it might be helpful to provide more details about your specific setup or any error messages you are encountering.
A5rocks commentedon Nov 7, 2024
This is expected, it very much has to do with what's in cache. I'm honestly not sure if setup-python is the culprit here. It appears that there's an incorrect file in the cachedir pip uses, for some reason.
Given that if I delete caches this problem disappears it makes sense you can't reproduce without those caches. However, it's notable this has happened to 2 projects with (probably) different CI setups. I'll go ahead and confirm whether its actually a cache issue (which would be apparant if we have disagreeing cached bodies and headers -- I think we do) and report back with findings.
A5rocks commentedon Nov 9, 2024
OK I'm pretty sure this is a pip issue. Here's the files in the http-v2 cache:
for some reason
pipisn't able to replace the tmpfile and yet it suppresses that error. I'll close this issue cause this issue is not related to this action.