-
-
Notifications
You must be signed in to change notification settings - Fork 270
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
No such file for interpreter's binary name #1009
Comments
This is hard to understand since FWICT all interpreter resolution funnels through here: IOW the path @asherf is there any chance you can re-run against the saved |
For example: With Pex 2.1.12:
Using a fresh interpreter cache for sanity sake:
So here's a similar base case. That leaves these cached interpreters from the PATH scan:
Now on to simulating a once present but now gone interpreter:
And really removing the 3.6 by removing its other hard link:
So it looks like the existence check is working in this mocked up simulation. |
@asherf : If you're still able to repro this, working with John on it would be helpful. |
doesn't repo anymore since I reinstalled my homebrew env. |
I'm going to close this since its both not reproduceable and the exercise above seems to indicate interpreter caching is robust to this sort of thing. |
OK, we've had another instance of this come up over in pantsbuild/pants#10855
I'll remove reliance on this assumption. |
Unfortunately, OSX framework Python interpreters have had launch schemes that could lead to misreported `sys.executable`. We no longer trust `sys.executable` when caching interpreters or reading them from the cache. Fixes pex-tool#1009
Unfortunately, OSX framework Python interpreters have had launch schemes that could lead to misreported `sys.executable`. We no longer trust `sys.executable` when caching interpreters or reading them from the cache. Fixes #1009 Co-authored-by: Eric Arellano <[email protected]>
The prior fix for pex-tool#1009 undid the fix in pex-tool#860. Re-enable that fix for any case that's clearly not in the context of a macOS Framework Python build. Also add tests for pyenv shims to prevent further regressions.
With
2.1.12
, @asherf encountered a case wherepex
detected an interpreter with a bad binary name:The file
/Users/asher/.toolchain/homebrew/Cellar/[email protected]/3.8.4/bin/python3.7
does not exist (python3.8
does, as might be expected).This bug was reproduced in the context of a long lived
pex_root
, which @asherf can provide if need be.The text was updated successfully, but these errors were encountered: