-
Notifications
You must be signed in to change notification settings - Fork 17
Make create_pip_script work with uv actually this time #185
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
Conversation
Weird hack to work around: astral-sh/python-build-standalone#380 If we resolve the symlink all the way, the python-host interpreter works but won't install into our pyodide venv. If we don't resolve the symlink, sys.prefix is calculated incorrectly. To ensure that we get the right sys.prefix, we explicitly set it with the PYTHONHOME environment variable and then call the symlink.
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for dealing with these issues.
(still needs the integration test, BTW) Edit: the integration label via #191 will make this a bit nicer. |
I think the pip shebang issue on macOS can be fixed by executing that with However, I don't know how to address the linux problem! My assumption is that pip is succeeding here, but not installing into the right venv? |
That does look like what happened. But I can try it on local dev and fix it manually. OTOH, I don't have a mac so your advice there is very much appreciated. |
Okay, I fixed at least a few problems. |
Okay, it's green. Gonna go ahead and merge this. Thanks again for your help @joerick! |
Thanks a lot, @hoodmane! |
And via manual testing I can confirm that it now works for me when |
@agriyakhetarpal would you mind making a patch release? |
Not sure what our versioning rule is. But if it's semver-esque, this change itself is not a breaking change. So unless there is another breaking change on the main branch that you're worried about, I'd call it 0.30.1. |
Ah, okay, makes sense to me. Triggering a new release, then! |
Actually, I checked and we do have some new changes merged after 0.30.0 that are strictly features (#186 and #187). So, coupled with this change, it makes for two user-facing features and one bug fix. Given that we don't have branches set up to backport this change—and maybe we don't need them either, unlike how we do for the main Pyodide repo—could we go ahead with 0.31.0, if you're okay with it? |
I've tried this in pypa/cibuildwheel#2002 (installing from |
This fixes a regression introduced in pyodide#185.
This fixes a regression introduced in pyodide#185.
This fixes a regression introduced in #185.
This fixes quoting in the pip arguments. Otherwise: ``` .venv-pyodide/bin/pip install 'pkg; sys_platform != "emscripten"' ``` will fail because the quotes are removed and it is interpretered as a request to install packages named pkg, sys_platform, !=, and emscripten. This fixes another regression introduced in pyodide#185.
This fixes quoting in the pip arguments. Otherwise: ``` .venv-pyodide/bin/pip install 'pkg; sys_platform != "emscripten"' ``` will fail because the quotes are removed and it is interpretered as a request to install packages named pkg, sys_platform, !=, and emscripten. This fixes another regression introduced in #185.
Weird hack to work around:
astral-sh/python-build-standalone#380
If we resolve the symlink all the way, the python-host interpreter works but won't install into our pyodide venv. If we don't resolve the symlink, sys.prefix is calculated incorrectly. To ensure that we get the right sys.prefix, we explicitly set it with the PYTHONHOME environment variable and then call the symlink.