mirror of
https://github.com/astral-sh/uv.git
synced 2025-08-04 19:08:04 +00:00
Always use base Python discovery logic for cached environments (#11254)
## Summary This is attempting to solve the same problem surfaced in #11208 and #11209. However, those PRs only worked for our own managed Pythons. In Gentoo, for example, they disable the managed Pythons, which led to failures in the test suite, because the "base Python" returned after creating a virtual environment would differ from the "base Python" that you get after _querying_ an existing virtual environment. The fix here is to apply our same base Python normalization and discovery logic, to non-standalone / non-managed Pythons. We continue to use `sys._base_executable` for such Pythons when creating the virtualenv, but when _caching_, we perform this second discovery step. Closes https://github.com/astral-sh/uv/issues/11237.
This commit is contained in:
parent
c0f6406c76
commit
53d1a7aa6e
3 changed files with 54 additions and 27 deletions
|
@ -56,7 +56,14 @@ pub(crate) fn create(
|
|||
) -> Result<VirtualEnvironment, Error> {
|
||||
// Determine the base Python executable; that is, the Python executable that should be
|
||||
// considered the "base" for the virtual environment.
|
||||
let base_python = interpreter.to_base_python()?;
|
||||
//
|
||||
// For consistency with the standard library, rely on `sys._base_executable`, _unless_ we're
|
||||
// using a uv-managed Python (in which case, we can do better for symlinked executables).
|
||||
let base_python = if cfg!(unix) && interpreter.is_standalone() {
|
||||
interpreter.find_base_python()?
|
||||
} else {
|
||||
interpreter.to_base_python()?
|
||||
};
|
||||
|
||||
debug!(
|
||||
"Using base executable for virtual environment: {}",
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue