Windows: uv doesn't find python versions on PATH

[MichaReiser]

I installed Python using pyenv-win but puffin can't find it (because it's not in the PATH). Running python from the command line works as expected and starship recognises it correctly too.

❯ python -V
Python 3.12.0

puffin on  main [?] is 📦 v0.0.4 via 🐍 v3.12.0 via 🦀 v1.75.0
❯ where.exe python
C:\Users\Micha\.pyenv\pyenv-win\shims\python
C:\Users\Micha\.pyenv\pyenv-win\shims\python.bat
C:\Users\Micha\AppData\Local\Microsoft\WindowsApps\python.exe

py --list-paths
 -V:IronPython/3.4 * C:\Program Files\IronPython 3.4\ipy.exe
 -V:IronPython/3.4-32 C:\Program Files\IronPython 3.4\ipy32.exe

puffin venv
  × Could not find `python.exe` in PATH and `py --list-paths` did not list any Python versions. Is Python installed?

Probably related to #1168

Work around: use pyenv which python and pass the path explicitly puffin pip -p <path_shown_by_pyenv_which>

[charliermarsh]

Nice, good find.

[MichaReiser]

The issue is probably more general and applies to all python versions that are on the PATH. See this comment

[gaborbernat]

Ran into this on Github Actions too, see https://github.com/tox-dev/tox-uv/actions/runs/7935511069?pr=2

[melMass]

Yep, uv seems to expect the global py (apparently a thing on windows)
I also use pyenv-win and pyenv on unix and have the same issue:

❯ uv venv
  × Failed to run `py --list-paths` to find Python installations. Is Python installed?
  ╰─▶ program not found

I tried all installation methods (cargo, pip, from source)

[zanieb]

@melMass is python.exe on your PATH?

[melMass]

@melMass is python.exe on your PATH?

Yep

Maybe the bat shims is causing an issue?

Specifying the path like this works fine:

uv venv -p (pyenv exec python -c "import sys; print(sys.executable)")

[zanieb]

It looks like python and python.bat are on your path, we don't support those shims yet. You should add python.exe to your path e.g. by adding the sys.executable folder you showed at the end to PATH.

Or, yes, you can use the full path to the interpreter executable directly

[melMass]

It looks like python and python.bat are on your path, we don't support those shims yet. You should add python.exe to your path e.g. by adding the sys.executable folder you showed at the end to PATH.

Thanks, it makes sense.

pyenv-win is a little finicky so I don't mind specifying the full path, I avoid global pythons at all cost, from experience it creates complex issues to debug (especially on windows)

In this case I think I'll use the cargo releases to avoid pip & pipx being responsible of uv

[MichaReiser]

I plan to work on this on Monday except someone beats me to it. Appreciate any pointers.

[zanieb]

We do correctly find python.exe with #1381. I think #1521 is the next major step for Windows Python discovery. I'm not sure if we have intermediate solutions, but we could maybe support python shims from pyenv-win like we do for pyenv on unix?

[gaborbernat]

@zanieb any idea why GitHub actions fails?

#1521 (comment)

[zanieb]

Hm this looks to be working in GitHub actions with setup-python over here https://github.com/astral-sh/uv/actions/runs/7944040120/job/21689087415?pr=1611

[ofek]

#1521 should not be the next step. I know that is a spec and I know that virtualenv supports that, but I guarantee you that it is generally unused in most scenarios and you should prioritize implementing lookups based on PATH. The way virtualenv works is that it will try the registry and if the result is not empty then use PATH but in all of my time in enterprise and on my personal machine it has always responded to modifications to PATH.

[zanieb]

@ofek can you please clarify what you'd like us to find on the PATH? We already will find python.exe.

[gaborbernat]

Hm this looks to be working in GitHub actions with setup-python over here astral-sh/uv/actions/runs/7944040120/job/21689087415?pr=1611

When called from within tox tox-dev/tox-uv#19 seems it fails though....

[gaborbernat]

@zanieb can you help what information exactly is used on Windows to create the environment today? Env-vars, and such 😊

[ofek]

@zanieb Yes I understand that but the issue is that you're not finding every single python.exe on PATH.

[MichaReiser]

Hm this looks to be working in GitHub actions with setup-python over here astral-sh/uv/actions/runs/7944040120/job/21689087415?pr=1611

When called from within tox tox-dev/tox-uv#19 seems it fails though....

This seems unrelated to the Python discovery because uv successfully starts to resovle dependencies but fails with Unable to extract filename from URL: d:\a\tox-uv\tox-uv\.tox\.tmp\package\1\tox_uv-0.1.dev1+g5039064-py3-none-any.whl

[MichaReiser]

According to pep514, py already makes use of the registry information. Therefore, implementing PEP514 is unlikely to help when trying to discover all python versions.

When installed on Windows, the official Python installer creates a registry key for discovery and detection by other applications. This allows tools such as installers or IDEs to automatically detect and display a user’s Python installations. For example, the PEP 397 py.exe launcher and editors such as PyCharm and Visual Studio already make use of this information.

Virtualenv has a fallback where it iterates over each path and tries to find the right python version https://github.com/pypa/virtualenv/blob/fa283474fd199e3836f8b2c99510190c6b77e2bc/src/virtualenv/discovery/builtin.py#L107-L120

[MichaReiser]

We do correctly find python.exe with #1381.

I think #1381 only fixes the problem for find_default_python but not when calling uv --python 3.8 where 3.8 is the default python installation