Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows 3.13t installation missing python.exe #8298

Open
colesbury opened this issue Oct 17, 2024 · 9 comments
Open

Windows 3.13t installation missing python.exe #8298

colesbury opened this issue Oct 17, 2024 · 9 comments
Labels
bug Something isn't working uv python Related to the uv python interface

Comments

@colesbury
Copy link

> uv run -p 3.13t python
error: Python interpreter not found at `C:\Users\Administrator\AppData\Roaming\uv\python\cpython-3.13.0+freethreaded-windows-x86_64-none\python.exe`

The installation directory has a python3.13t.exe, but no python.exe

This also affects other commands like uv venv.

@zanieb
Copy link
Member

zanieb commented Oct 17, 2024

python/cpython#112984 (comment) says

The installer should not include a python.exe, to avoid causing PATH conflicts, but Nuget, embeddable and Store packages should include a copy/alias.

so I guess we should add one in our installs? I wonder if we should do that upstream or here.

@zanieb zanieb added the uv python Related to the uv python interface label Oct 17, 2024
@colesbury
Copy link
Author

My suggestion would be to rename the python3.13t.exe to python.exe in the indygreg/python-build-standalone build process, especially because the python-build-standalone Windows executables don't otherwise include the Python version numbers in their names.

@zanieb
Copy link
Member

zanieb commented Oct 17, 2024

especially because the python-build-standalone Windows executables don't otherwise include the Python version numbers in their names.

As far as I know, we're just following the standard Windows build behavior there (not including version numbers), and it's proper for us to continue doing so for python3.13t.exe (which is the canonical name CPython uses here)

Since they suggest creating a copy, I think that's what I'll do? Exploring in indygreg/python-build-standalone#373

@zanieb zanieb added the bug Something isn't working label Oct 17, 2024
@zanieb
Copy link
Member

zanieb commented Oct 17, 2024

cc @zooba if you care to weigh in on what is best here.

@colesbury
Copy link
Author

As a overall suggestion: I think you should be aiming for cross-platform consistency -- uv is a cross-platform product -- rather than consistency with parts of the CPython Windows installer (or macOS installer for that matter). People will expect that uv commands that work on Linux and macOS to also work on Windows.

For example, I think all of the following commands should work on all platforms:

uv run -p 3.10 python
uv run -p 3.10 python3.10

uv run -p 3.13t python
uv run -p 3.13t python3.13
uv run -p 3.13t python3.13t

@zooba
Copy link

zooba commented Oct 17, 2024

Yeah, I largely agree with Sam here, cross-platform consistency is for the best. We only don't do that in the Windows installer because it's a change that will definitely break people, and I don't want to upset people more until we've actually got a sustainable path forward. uv is much closer to that vision than PATH modifications will ever be.

@zanieb
Copy link
Member

zanieb commented Oct 17, 2024

Great thanks for the input! I'll rename it upstream — makes life a bit easier anyway.

I'm not sure what the best approach will be to address your uv run examples, but generally agree with the philosophy that the commands should be portable across platforms.

Thanks again @colesbury for following up on our handling of these distributions, there are definitely some quirks to be ironed out.

zanieb added a commit that referenced this issue Oct 17, 2024
A temporary fix for #8298 while we
wait for my slower upstream fix at
indygreg/python-build-standalone#373

I think we'll want this machinery anyway to ensure that the various
executable names are available? Otherwise we need to special-case all
the `python` names in `uv run`?

We don't have unit test coverage of managed downloads, so I added an
[integration
test](https://github.com/astral-sh/uv/actions/runs/11394150653/job/31703956805?pr=8310)
similar to what we have for Linux.
@colesbury
Copy link
Author

@zanieb - running uv run -p 3.13t python works for me today on Windows, but I see that your PR to python-build-standalone has not landed, so I'm not sure what changed.

I've run into some other confusing behavior where uv python list temporarily did not show 3.13t as installed, but uv python install 3.13t reported it as installed. I'm unable to reliably reproduce the behavior.

C:\Users\Administrator>uv python install 3.13t
Searching for Python versions matching: Python 3.13t
Found existing installation for Python 3.13t: cpython-3.13.0+freethreaded-windows-x86_64-none

C:\Users\Administrator>uv python list
cpython-3.13.0-windows-x86_64-none     <download available>
cpython-3.12.7-windows-x86_64-none     <download available>
cpython-3.11.10-windows-x86_64-none    <download available>
cpython-3.10.15-windows-x86_64-none    <download available>
cpython-3.9.20-windows-x86_64-none     <download available>
cpython-3.8.20-windows-x86_64-none     <download available>
cpython-3.7.9-windows-x86_64-none      <download available>
pypy-3.10.14-windows-x86_64-none       <download available>
pypy-3.9.19-windows-x86_64-none        <download available>
pypy-3.8.16-windows-x86_64-none        <download available>
pypy-3.7.13-windows-x86_64-none        <download available>

C:\Users\Administrator>uv python install 3.13t
Searching for Python versions matching: Python 3.13t
Found existing installation for Python 3.13t: cpython-3.13.0+freethreaded-windows-x86_64-none

C:\Users\Administrator>uv run -p 3.13t python
Python 3.13.0 experimental free-threading build (main, Oct 16 2024, 00:29:34) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

C:\Users\Administrator>uv python list
cpython-3.13.0+freethreaded-windows-x86_64-none    AppData\Roaming\uv\python\cpython-3.13.0+freethreaded-windows-x86_64-none\python.exe
cpython-3.12.7-windows-x86_64-none                 <download available>
cpython-3.11.10-windows-x86_64-none                <download available>
cpython-3.10.15-windows-x86_64-none                <download available>
cpython-3.9.20-windows-x86_64-none                 <download available>
cpython-3.8.20-windows-x86_64-none                 <download available>
cpython-3.7.9-windows-x86_64-none                  <download available>
pypy-3.10.14-windows-x86_64-none                   <download available>
pypy-3.9.19-windows-x86_64-none                    <download available>
pypy-3.8.16-windows-x86_64-none                    <download available>
pypy-3.7.13-windows-x86_64-none                    <download available>

@zanieb
Copy link
Member

zanieb commented Oct 21, 2024

@colesbury I added #8310 as a temporary workaround in uv — just much easier to land a quick change here than upstream.

I'll try to look into that uv python list behavior, sounds pretty weird. If you can get RUST_LOG=uv=trace uv python list -v logs on the failure that'd be helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working uv python Related to the uv python interface
Projects
None yet
Development

No branches or pull requests

3 participants