pip not installed by default in aarch64-unknown-linux-gnu-noopt build #84
Labels
bug
Something isn't working
Comments
|
This is definitely an unintended bug. Thanks for reporting it. This appears to only materialize in cross-builds. I think what's happening is because we use the host Things may get gnarly here. But I suspect we can coerce this into working without having to use an emulator to run the target Python. I'll try to look into this the next time I hack on this project. |
indygreg
added a commit
that referenced
this issue
Aug 31, 2021
This commit refactors the install of pip and setuptools. Previously, we installed both of these by invoking `setup.py` from the host Python. This worked, but it was somewhat old school. And in the case of cross-compiling, it installed the packages to the host Python, not the target Python. After this commit, we download wheels for both pip and setuptools and the install invokes the host Python but runs the pip wheel to invoke pip to install the packages. This is conceptually similar to how the `ensurepip` module works. The end result is that pip is used to install itself and setuptools into the appropriate output directory. This works with both native and cross builds. Aside from minor changes to the directory layout, the end result is the same as far as I can tell. But since cross-compiles now install pip and setuptools correctly, this fixes #84. Because pip now bootstraps self and this doesn't work on musl builds without a patch, we had to move the patching of pip to before it is invoked. We moved the patching of setuptools as well, because it is related.
indygreg
added a commit
that referenced
this issue
Sep 3, 2021
This commit refactors the install of pip and setuptools. Previously, we installed both of these by invoking `setup.py` from the host Python. This worked, but it was somewhat old school. And in the case of cross-compiling, it installed the packages to the host Python, not the target Python. After this commit, we download wheels for both pip and setuptools and the install invokes the host Python but runs the pip wheel to invoke pip to install the packages. This is conceptually similar to how the `ensurepip` module works. The end result is that pip is used to install itself and setuptools into the appropriate output directory. This works with both native and cross builds. Aside from minor changes to the directory layout, the end result is the same as far as I can tell. But since cross-compiles now install pip and setuptools correctly, this fixes #84. Because pip now bootstraps self and this doesn't work on musl builds without a patch, we had to move the patching of pip to before it is invoked. We moved the patching of setuptools as well, because it is related.
|
I force pushed the commit that fixes this off I plan to reintroduce this fix once I figure out the problems with the latest 3.8 and 3.9 versions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
pip is not available right after extracting the aarch64 linux build of Python 3.9.6 (20210724).
Fortunately, it has the ensurepip with a bundled pip package, so I could workaround this by running
python -m ensurepiponce.I'm reporting this to prevent other people from having the same gotcha.
From cpython-3.9.6-x86_64-unknown-linux-gnu-pgo-20210724T1424.tar.zst:
From cpython-3.9.6-aarch64-unknown-linux-gnu-noopt-20210724T1424.tar.zst:
The text was updated successfully, but these errors were encountered: