Closed richlander closed 2 weeks ago
/azp run dotnet-buildtools-prereqs-docker-alpine
Yup. I'm still working the Arm32 Dockerfile. Fun!
The py3-cryptography
satisfies the dependency of our wheel. Installing that works.
I also found that if we want to build all the wheels from source, we can do the following:
apk update && apk add --no-cache \
build-base \
cargo \
libffi-dev \
gcc \
linux-headers \
openssl-dev
The cryptography package uniquely requires cargo
and openssl-dev
. If we instead use py3-cryptography
, then those two packages can be removed. We need gcc
and friends to build other packages, like psutil
. The more we can align our dependencies with the binary wheel distributions in the package manager, the better.
Fixes #1093.
I tried to use
py3-psutil
from Alpine but was unable to do so due to the way dependencies are specified in the helix wheel we install. Instead, thepsutil
is built from source (withgcc
). Explained in more detail at #1092.I switched to
venv
fromvirtualenv
since the former comes with Python3 distributions. AFAICT,virtualenv
is more a legacy Python 2-ism.The way we install
pip
andvirtualenv
is anti-pattern as I've written before. In some Dockerfiles I've seen, we installpip
three times in a row. "Gotta be sure!"I've tried to address these problems, however, there is a quite possible chance that we're either need to change the way these images are launched or go back to
--break-system-packages
, like we do in Debian. I really want to get away from that, since it is a clear demonstration that we're unable to use Python as it is designed.Due to what is discussed in #1093, I actually used the virtual environment for what it is intended for, which is