uv-tool/install: ignore existing environments on interpreter mismatch

[lucab]

This changes uv tool install behavior with regards to re-using existing environments.
In particular, this replaces the existing version-matching logic with a tighter one, enforcing
a same-interpreter match.
This allows to properly switch between system and managed interpreter, at the cost of
more eagerly invalidating existing environments every time there is an interpreter change.

Closes: #7320

[lucab]

Note: drive-by change to make debug logs more uniform. After this, the output now looks like this:

DEBUG Found existing environment for tool `poetry`: .local/share/uv/tools/poetry
DEBUG Found existing interpreter for tool `poetry`: /home/lucab/.local/share/uv/tools/poetry/bin/python3

[lucab]

It looks like I'm hitting some Windows-only different/buggy behavior, or some non-determinism in the CI there, which I'm trying to narrow down.

The symptom is that, on Windows runner only, running the same command twice results in the interpreter binary jumping around.
That is, this simple uv tool install black on the second run will trigger environment invalidation due to a different interpreter:

uv/crates/uv/tests/tool_install.rs

Lines 843 to 855 in f679987

	// Install `black` again
	uv_snapshot!(context.filters(), context.tool_install()
	.arg("black")
	.env("UV_TOOL_DIR", tool_dir.as_os_str())
	.env("XDG_BIN_HOME", bin_dir.as_os_str())
	.env("PATH", bin_dir.as_os_str()), @r###"
	success: true
	exit_code: 0
	----- stdout -----
	----- stderr -----
	`black` is already installed
	"###);

Snapshot: tool_install_already_installed-3
[...]
    4     4 │ ----- stderr -----
    5       │-`black` is already installed
          5 │+Ignored existing environment for `black` due to stale Python interpreter
          6 │+Interpreter mismatch: old='[TEMP_DIR]/tools/black/Scripts/python' vs new='[PYTHON-3.12]'

[lucab]

I've abused the CI to run a few more tests, and found out that this failure on the Windows CI is specific to using a "system" interpreter.
The logic works and test is passing when forcing a managed interpreter via --python-preference only-managed, but fails in all other cases.

My hypothesis here is that there is indeed a difference in the OSes, when creating the venv and setting up the interpreter. On Unix this is done through symlinks (targeting the same binary file in the end) which Windows does not generally have, so there is some file duplication involved (thus failing the is_same_file() check).

[lucab]

For future reference, things we tried in this PR but didn't work due to false positive mismatches detected:

• comparing interpreter binaries on-disk (via same-file): on Windows, interpreter files are copied around thus always mismatching
• comparing interpreter paths: also on Windows, minor name differences and versioning (e.g. python vs python3) which result in mismatches

Eventually settled on comparing base_prefix as proxy, as suggested by @zanieb.

[zanieb]

We'll always find an existing interpreter, maybe this should say something like... "Existing interpreter matches the requested interpreter"? I'd also be okay with lowering this to a trace log.

[zanieb]

My intuition is that this should be "Ignoring" but I'm not sure if that's clear in our style guide. If you search though, we use "Ignoring" consistently but not "Ignored".

Is the meaning of "stale" clear here? I worry it's not clear to the user if that means something is wrong with the existing interpreter or not. We might want to say something like "Ignoring existing environment for {from}: the requested Python interpreter does not match the environment interpreter". Wdyt?

[zanieb]

This isn't super obvious, but I think this can fetch a Python managed version during the test which we currently avoid (downstream packagers do not like it). I think this test may also be brittle depending on the developer's machine — the test context is happy with whatever Python versions it can find whether they are system or managed. I am not sure how to properly write a test for this though :/ it seems like a pain.

[zanieb]

For the sake of your time, I'd recommend omitting test coverage and opening an issue to add it. We'll need to consider a comprehensive solution here.

[lucab]

I can split the new cases apart in a different test and mark it as ignored, if you like. That should still allow running the test manually if needed, but won't impact packagers.
I'll open a ticket about testing with system interpreters.

[lucab]

#7473

[lucab]

$ cargo nextest run --run-ignored all tool_install_python_preference
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.29s
------------
 Nextest run ID 110712ea-a0a0-436a-ab95-4cdfbb384338 with nextest profile: default
    Starting 1 test across 86 binaries (1651 tests skipped)
        PASS [   6.088s] uv::tool_install tool_install_python_preference
------------
     Summary [   6.089s] 1 test run: 1 passed, 1651 skipped

[zanieb]

Nice work!