uv
uv copied to clipboard
[0.1.19 regression] `uv` no longer uses the Python interpreter set by `pyenv`
From version 0.1.19 onwards, uv seems to no longer respect the Python interpreter set by using pyenv local, even though it did on previous versions. This still reproduces on the latest version (uv==0.1.21). Reproducer in the shell to show that this worked with uv==0.1.18, but not on later versions (the "Using Python 3.XX.X lines are the relevant ones that demonstrate the bug):
% pyenv local 3.11 ~/dev/typeshed
% py --version ~/dev/typeshed
Python 3.11.8
% pipx install uv==0.1.18 --force ~/dev/typeshed
Installing to existing venv 'uv'
installed package uv 0.1.18, installed using Python 3.12.2
These apps are now globally available
- uv
done! β¨ π β¨
% uv venv 311-env ~/dev/typeshed
Using Python 3.11.8 interpreter at: /Users/alexw/.pyenv/versions/3.11.8/bin/python3
Creating virtualenv at: 311-env
Activate with: source 311-env/bin/activate
% rm -rf 311-env ~/dev/typeshed
% pipx install uv==0.1.19 --force ~/dev/typeshed
Installing to existing venv 'uv'
installed package uv 0.1.19, installed using Python 3.12.2
These apps are now globally available
- uv
done! β¨ π β¨
% uv venv 311-env ~/dev/typeshed
Using Python 3.12.2 interpreter at: /usr/local/bin/python3
Creating virtualenv at: 311-env
Activate with: source 311-env/bin/activate
% rm -rf 311-env ~/dev/typeshed
% pipx upgrade uv ~/dev/typeshed
upgraded package uv from 0.1.19 to 0.1.21 (location: /Users/alexw/Library/Application Support/pipx/venvs/uv)
% uv venv 311-env ~/dev/typeshed
Using Python 3.12.2 interpreter at: /usr/local/bin/python3
Creating virtualenv at: 311-env
Activate with: source 311-env/bin/activate
Hm I'm not sure what would have caused this from the CHANGELOG.
The next steps are perhaps:
- Ensure the expected behavior here is compliant with the proposed behavior in #2386
- Bisect the commit that introduced the regression
- Add a system check test covering this (these do not support assertions a specific version is used yet)
- Ensure the expected behavior here is compliant with the proposed behavior in #2386
/Users/alexw/.pyenv/shims is on my PATH -- does that satisfy this point? It looks like using pyenv shims has been supported since at least https://github.com/astral-sh/uv/pull/1711, but perhaps we never officially declared support. I certainly found it very useful when uv did support pyenv shims :-)
I'll try bisecting this to a specific commit now.
7964bfbb2bed50a5c7b0650a7b6799a66503a33a is the first bad commit
commit 7964bfbb2bed50a5c7b0650a7b6799a66503a33a
Author: konsti <[email protected]>
Date: Wed Mar 13 12:51:14 2024 +0100
Move architecture and operating system probing to Python (#2381)
7964bfbb2bed50a5c7b0650a7b6799a66503a33a by @konstin
Explicitly passing the Python version using the --python flag also seems to fail:
% python3.11
Python 3.11.8 (main, Feb 15 2024, 19:32:18) [Clang 15.0.0 (clang-1500.1.0.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
% uv venv --python 3.11 ~/dev/mypy
Γ Querying Python at `/Users/alexw/.pyenv/shims/python3.11` failed with status exit status: 127 with exit status: 127
β --- stdout:
β --- stderr:
β pyenv: python3.11: command not found
β The `python3.11' command exists in these Python versions:
β 3.11.8
β Note: See 'pyenv help global' for tips on allowing both
β python2 and python3 to be found.
β ---
[1] % uv venv --python 3.11.8 ~/dev/mypy
Γ Querying Python at `/Users/alexw/.pyenv/shims/python3.11` failed with status exit status: 127 with exit status: 127
β --- stdout:
β --- stderr:
β pyenv: python3.11: command not found
β The `python3.11' command exists in these Python versions:
β 3.11.8
β Note: See 'pyenv help global' for tips on allowing both
β python2 and python3 to be found.
β ---
Donβt see any inherent reason that that change should break pyenv. I can take a look on Monday.
Oh my guess is that it's because we now run that in a temporary directory...? Rather than the current working directory?
Oh that seems like it would break the shim, interesting
I still wish we could concat all the files into one :)
We could put it in a zipapp... :)
I tried, it actually is meaningfully slower lol
Confirmed that this is fixed in uv==0.1.22 π₯³