[th/ktoolbox-wheel-url] ktoolbox: install ktoolbox package using wheel URL

[thom311]

Previously, we used git+https:// URL with a fixed commit SHA to the ktoolbox version. This has the benefit that the commit SHA cryptographically encodes the code we are going to pull and build.

In jenkins CI, we reuse a venv and install it via pip install -r requirements.txt. Sometimes this venv gets corrupted. It is unclear why this happens. Could this be related to rebuilding the ktoolbox package from a git checkout?

Try to use instead the wheel file. ktoolbox automatically builds a wheel file, pushes it to a "gh-pages" branch ([1]) and exposes it on github pages ([2]). See the README ([3]) how that can be used.

We could directly refer to the github pages file using URL

https://thom311.github.io/ktoolbox/wheels/141.7708daaf4f8c/ktoolbox-0.8.0-py3-none-any.whl

but instead get to the exactly same file via

https://raw.githubusercontent.com/thom311/ktoolbox/8d5ce796bf07cf7a612084cfa7a6f4387ef0640c/wheels/141.7708daaf4f8c/ktoolbox-0.8.0-py3-none-any.whl

This has the benefit that 8d5ce796bf07cf7a612084cfa7a6f4387ef0640c cryptographically ensures that we are referring to a certain commit in github, which I trust to contain the code build from commit 7708daaf4f8c. Technically, unlike the git+https URL, this does not ensure that the wheel file was really build based on commit 7708daaf4f8c. But I know that this was the case for commit 8d5ce796bf07cf7a612084cfa7a6f4387ef0640c, so we can have a slightly higher confidence to pull what we expect.

[1] https://github.com/thom311/ktoolbox/commits/gh-pages/
[2] https://thom311.github.io/ktoolbox/wheels/
[3] https://github.com/thom311/ktoolbox/blob/f083da6fa0cc2deb47751f201dc6dcbb81616f77/README.md#installation-and-wheel-files

[wizhaoredhat]

LGTM llet's try it.