-
Notifications
You must be signed in to change notification settings - Fork 543
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
Python toolchain cache invalidation #2283
Comments
Can you provide more info? In particular, reproduction steps or output that indicates something isn't being cached. |
Yes, the hermetic interpreters are downloaded again and all the pip
dependencies are reinstalled
…On Wed, Oct 9, 2024 at 5:31 PM Richard Levasseur ***@***.***> wrote:
Can you provide more info? In particular, reproduction steps or output
that indicates something isn't being cached.
—
Reply to this email directly, view it on GitHub
<#2283 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABACPPIXUJ45BBMQV7CYJTZ2W4F3AVCNFSM6AAAAABPVPI5P6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTGYYTONJUGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Does #2256 fix the cache invalidation you are seing? |
It appears so - I have not been able to reproduce using that commit. Closing. |
@ewhauser, could you add context for reopening this issue? |
Think I closed this prematurely. This behavior still seems to exist in |
I bisected and this is the offending commit: |
Interesting 68c3048 would have been my last guess here. What is the toolchain matching log if you pass FYI: @rickeylev |
Yes, I agree. I've bisected it 3 separate times and always ended up at this commit. Pinned to the previous commit in our monorepo and the problem is solved.
The other piece of information I can give is that the repro seems to be:
and the dependent repositories are invalidated. I've tried to extract this into a simple repo without luck yet. |
That is a weird commit to be the cause. All that local toolchain stuff isn't active. Maybe the changes to repo_utils.bzl? It introduces some getenv() and watch() calls. Maybe something about that is over-triggering? |
Looking through the code, the new watch/getenv calls I see are:
which() is called as part some of the runtime repo setup, iirc. In repo_utils (https://github.com/bazelbuild/rules_python/blob/main/python/private/repo_utils.bzl), if you:
Does the invalidation go away? |
🐞 bug report
Affected Rule
rules_python 0.35.0
Is this a regression?
Yes
Description
The latest version of
rules_python
is not caching the Python toolchain correctly on OSX.🔬 Minimal Reproduction
🌍 Your Environment
Operating System:
Output of
bazel version
:Rules_python version:
Anything else relevant?
This occurs in both
WORKSPACE
and bzlmod builds.The text was updated successfully, but these errors were encountered: