pip not installed by default in aarch64-unknown-linux-gnu-noopt build

[achimnol]

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 ensurepip once.
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:

> find python/install -name '*pip*'
./lib/python3.9/test/test_pipes.py
./lib/python3.9/test/test_ensurepip.py
./lib/python3.9/pipes.py
./lib/python3.9/ensurepip
./lib/python3.9/ensurepip/_bundled/pip-21.1.3-py3-none-any.whl
./lib/python3.9/site-packages/pip-21.1.3-py3.9.egg
./lib/python3.9/site-packages/pip-21.1.3-py3.9.egg/pip
./bin/pip3
./bin/pip3.9
./bin/pip

From cpython-3.9.6-aarch64-unknown-linux-gnu-noopt-20210724T1424.tar.zst:

> find python/install -name '*pip*'
./lib/python3.9/test/test_pipes.py
./lib/python3.9/test/test_ensurepip.py
./lib/python3.9/pipes.py
./lib/python3.9/ensurepip
./lib/python3.9/ensurepip/_bundled/pip-21.1.3-py3-none-any.whl

[indygreg]

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 python to install pip it gets installed to the host python and not the target python we're cross-compiling to.

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]

I force pushed the commit that fixes this off main because I'm running into issues with the latest Python 3.8 and 3.9 releases which introduced a build regression.

I plan to reintroduce this fix once I figure out the problems with the latest 3.8 and 3.9 versions.