Use base Python for cached environments #11208
Merged
+201
−146
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
It turns out that we were returning slightly different interpreter paths on repeated
uv run --with
commands. This likely didn't affect many (or any?) users, but it does affect our test suite, since in the test suite, we use a symlinked interpreter.The issue is that on first invocation, we create the virtual environment, and that returns the path to the
python
executable in the environment. On second invocation, we return thepython3
executable, since that gets priority during discovery. This on its own is potentially ok. The issue is that these resolve to differentsys._base_executable
values in these flows... The latter gets the correct value (since it's read from thehome
key), but the former gets the incorrect value (since it's just thebase_executable
of the executable that created the virtualenv, which is the symlink).We now use the same logic to determine the "cached interpreter" as in virtual environment creation, to ensure consistency between those paths.