uv Python setup fails on Windows: "spawn uv ENOENT" after fresh uv install

Start in extensions/positron-python/src/client/pythonEnvironments/common/environmentManagers/uvPythonInstaller.ts at installPythonVersionAndGetPath(), then compare its uv calls with callers using UvUtils and uvUtils.command. Done means fresh Windows installs can run both uv Python commands through the resolved binary after installation, avoiding spawn ENOENT.

When Positron installs uv for the user and then tries to install a Python version, the install step fails with Failed to install Python 3.14: Error: spawn uv ENOENT even though uv installed successfully moments earlier. This happens mostly because uv isn't on the path yet.

Reported via reddit:

https://www.reddit.com/r/RStudio/comments/1vybexp/question_on_positron_and_python_failed_to_install/

Root cause

installPythonVersionAndGetPath() in extensions/positron-python/src/client/pythonEnvironments/common/environmentManagers/uvPythonInstaller.ts calls execUv with the literal command 'uv':

execUv('uv', ['python', 'install', installTarget], ...)
execUv('uv', ['python', 'find', version], ...)

Every other uv call routes through UvUtils, which locates the binary and uses the resolved path (uvUtils.command, e.g. ~\.local\bin\uv.exe). Right after a fresh install, uv is not on the running extension host's PATH -- the installer only updates shell rc / registry PATH, which the already-running process doesn't pick up. So the bare 'uv' spawn fails with ENOENT, while the resolved absolute path works.

Evidence (from the user's log)

> uv --color never python dir                    (bare 'uv' probe -> fails, falls back)
> ~\.local\bin\uv.exe --color never python dir   (resolved path -> works)
> ~\.local\bin\uv.exe --color never python list  (resolved path -> works)
Installing Python 3.14 via uv...
> uv --color never python install 3.14           (bare 'uv' -> ENOENT)
Failed to install Python 3.14: Error: spawn uv ENOENT

The bare-'uv' probe already failing (and the fallback to ~\.local\bin\uv.exe succeeding) confirms uv is not on this session's PATH.

Note: this is not strictly "uv" vs "uv.exe" -- bare 'uv' would resolve fine if it were on PATH. The bug is that this one code path uses the literal 'uv' instead of the located binary path that the rest of the flow already resolved.

Fix (suggested)

Use the resolved uv command in installPythonVersionAndGetPath instead of the literal 'uv' (route through the located UvUtils / uvUtils.command, same as the other callers). The existing comment there says it avoids installUvPython "to avoid cache issues," but resetUvCache() has already run after install, so the located command is current -- the resolved path can be used safely.

Platform: Windows. Not reproducible where uv is already on PATH.