The Meson Build System http://mesonbuild.com/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

50 lines
793 B

#!/bin/bash
###
### Common functions for CI builder files.
### All functions can be accessed in install.sh via:
###
### $ source /ci/common.sh
###
set -e
set -x
base_python_pkgs=(
pytest
pytest-xdist
pytest-subtests
coverage
jsonschema
)
python_pkgs=(
cython
gobject
PyGObject
lxml
gcovr
)
dub_fetch() {
set +e
for (( i=1; i<=24; ++i )); do
dub fetch "$@"
(( $? == 0 )) && break
echo "Dub Fetch failed. Retrying in $((i*5))s"
sleep $((i*5))
done
set -e
}
install_minimal_python_packages() {
ciimage: fix pathological brokenness in Debian packaging of python In this case, PEP 668 was created to allow a thing that Debian wanted, which is for `pip install foobar` to not break the system python. This despite the fact that the system python is fine, unless you use sudo pip which is discouraged for separate reasons, and it is in fact quite natural to install additional packages to the user site-packages. It isn't even the job of the operating system to decide whether the user site-packages is broken, whether the operating system gets the answer correct or not -- it is the job of the operating system to decide whether the operating system is broken, and that can be solved by e.g. enforcing a shebang policy for distribution-packaged software, which distros like Fedora do, and mandating not only that python shebangs do not contain `/usr/bin/env`, but that they *do* contain -s. Anyway, this entire kerfuffle is mostly just a bit of pointless interactive churn, but it bites pretty hard for our use case, which is a container image which is fortunately tested before deployment, so instead of failing to deploy because of theoretical conflicts with the base system (we specifically need base system integration...) we fail to deploy because 5 minutes into pulling apt updates at the very beginning, pip refuses point-blank to work. I especially do not know why it is the job of the operating system to throw errors intended for interactive users at people baking "appliance" containers who cannot "break" the system python anyway. Fix this by doing what Debian and Ubuntu should both have done from the beginning, and opting containers out of this questionable feature entirely. Note that CI images may still not actually complete their build/test cycle and be updated, because e.g. LLVM 16 issues tracked by #11642 or glib ASAN issues tracked by #11754.
2 years ago
rm -f /usr/lib/python3.*/EXTERNALLY-MANAGED
python3 -m pip install "${base_python_pkgs[@]}" $*
}
install_python_packages() {
ciimage: fix pathological brokenness in Debian packaging of python In this case, PEP 668 was created to allow a thing that Debian wanted, which is for `pip install foobar` to not break the system python. This despite the fact that the system python is fine, unless you use sudo pip which is discouraged for separate reasons, and it is in fact quite natural to install additional packages to the user site-packages. It isn't even the job of the operating system to decide whether the user site-packages is broken, whether the operating system gets the answer correct or not -- it is the job of the operating system to decide whether the operating system is broken, and that can be solved by e.g. enforcing a shebang policy for distribution-packaged software, which distros like Fedora do, and mandating not only that python shebangs do not contain `/usr/bin/env`, but that they *do* contain -s. Anyway, this entire kerfuffle is mostly just a bit of pointless interactive churn, but it bites pretty hard for our use case, which is a container image which is fortunately tested before deployment, so instead of failing to deploy because of theoretical conflicts with the base system (we specifically need base system integration...) we fail to deploy because 5 minutes into pulling apt updates at the very beginning, pip refuses point-blank to work. I especially do not know why it is the job of the operating system to throw errors intended for interactive users at people baking "appliance" containers who cannot "break" the system python anyway. Fix this by doing what Debian and Ubuntu should both have done from the beginning, and opting containers out of this questionable feature entirely. Note that CI images may still not actually complete their build/test cycle and be updated, because e.g. LLVM 16 issues tracked by #11642 or glib ASAN issues tracked by #11754.
2 years ago
rm -f /usr/lib/python3.*/EXTERNALLY-MANAGED
python3 -m pip install "${base_python_pkgs[@]}" "${python_pkgs[@]}" $*
}