You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I stumbled into this issue where installing pyodide-build in a uv-managed venv and then running pyodide xbuildenv install <...> to set up a cross-build environment fails with the following logs, because we hardcode the pip install <...> command here:
A simple fix is to add a small try-catch block that runs another uv pip install command in a subprocess in case the pip one fails – I implemented this locally, and it seems to work well. We could go further and also check what is available beforehand by using shutil.which().
Additional comments
I'm not sure if this is a valid issue (please feel free to close if it is), but since uv is gaining popularity in the Python ecosystem, might it be worth exploring the short (albeit hacky) fix I suggested above? I can work with `virtualenv'- managed environments for some time – though, I'm sure someone is going to come across this in the same way as I did.
The other thing I'd say is that it's always better to be explicit about the Python interpreter being used, so we should at least change the use of this command (and uses elsewhere), to use f"{sys.executable}", "-m", "pip" to avoid the chance of breaking external environments.
The text was updated successfully, but these errors were encountered:
If [sys.executable, "-m", "pip", ...] works, that sounds good to me. Testing ahead of time with shutil.which() would also be okay with me. I don't like catching an error in subprocess and retrying.
Description
I stumbled into this issue where installing
pyodide-build
in auv
-managed venv and then runningpyodide xbuildenv install <...>
to set up a cross-build environment fails with the following logs, because we hardcode thepip install <...>
command here:pyodide-build/pyodide_build/xbuildenv.py
Lines 297 to 312 in f78d587
and
uv
removes thepip
executable wrapper from its environments when activated so that a systempip
isn't used in favour ofuv pip
:Tap to show logs
Steps to reproduce
uv venv venv --python 3.X source venv/bin/activate uv pip install pyodide-build pyodide xbuildenv install 0.27.0a2
Potential fix
A simple fix is to add a small try-catch block that runs another
uv pip install
command in a subprocess in case thepip
one fails – I implemented this locally, and it seems to work well. We could go further and also check what is available beforehand by usingshutil.which()
.Additional comments
I'm not sure if this is a valid issue (please feel free to close if it is), but since
uv
is gaining popularity in the Python ecosystem, might it be worth exploring the short (albeit hacky) fix I suggested above? I can work with `virtualenv'- managed environments for some time – though, I'm sure someone is going to come across this in the same way as I did.The other thing I'd say is that it's always better to be explicit about the Python interpreter being used, so we should at least change the use of this command (and uses elsewhere), to use
f"{sys.executable}", "-m", "pip"
to avoid the chance of breaking external environments.The text was updated successfully, but these errors were encountered: