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

pip cache has old version of http cache on Windows+pypy #972

Closed
2 of 5 tasks
A5rocks opened this issue Oct 27, 2024 · 6 comments
Closed
2 of 5 tasks

pip cache has old version of http cache on Windows+pypy #972

A5rocks opened this issue Oct 27, 2024 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@A5rocks
Copy link

A5rocks commented Oct 27, 2024

Description:

When installing pypy using setup-python, the cache seems to be old? I'm not too sure the exact reason for why.

Action version:

commit f677139

Platform:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

Tools version:

pypy 3.10

Repro steps:

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.

@A5rocks A5rocks added bug Something isn't working needs triage labels Oct 27, 2024
@priya-kinthali
Copy link
Contributor

Hello @A5rocks 👋,
Thank you for reporting this issue. We will investigate it and get back to you as soon as we have some feedback.

@mahabaleshwars mahabaleshwars self-assigned this Oct 29, 2024
@mahabaleshwars
Copy link

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
Copy link
Author

A5rocks commented 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.

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.

@mahabaleshwars
Copy link

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.Image

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
Copy link
Author

A5rocks commented Nov 7, 2024

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.

@A5rocks
Copy link
Author

A5rocks commented Nov 9, 2024

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.

@A5rocks A5rocks closed this as not planned Won't fix, can't repro, duplicate, stale Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants