uv/crates/uv-python
Charlie Marsh 34552e2d3d
Use base Python for cached environments (#11208)
## 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 the `python3` executable,
since that gets priority during discovery. This on its own is
potentially ok. The issue is that these resolve to different
`sys._base_executable` values in these flows... The latter gets the
correct value (since it's read from the `home` key), but the former gets
the incorrect value (since it's just the `base_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.
2025-02-04 17:23:06 -05:00
..
python Use explicit _GLibCVersion tuple in uv-python crate (#11122) 2025-01-31 11:52:38 +01:00
src Use base Python for cached environments (#11208) 2025-02-04 17:23:06 -05:00
Cargo.toml Install and remove managed Python to and from the Windows Registry (PEP 514) (#10634) 2025-01-23 14:13:41 +00:00
download-metadata.json Sync latest Python releases (#10637) 2025-01-15 12:55:31 -06:00
fetch-download-metadata.py Update references to python-build-standalone to reflect the transferred project (#9977) 2024-12-17 20:19:58 +00:00
template-download-metadata.py Update riscv64 Python downloads to allow install on riscv64gc (#10937) 2025-01-24 09:33:29 -06:00