On the 2026.1 release, the demos/python-demos/requirements.txt has the following lines:
optimum-intel@git+https://github.com/huggingface/optimum-intel.git
That means it builds the wheel at HEAD on main. This is not good for reproducibility. The same issue can be found in prepare_llm_models.sh, at line 48 is:
python3 -m pip install "optimum-intel"@git+https://github.com/huggingface/
optimum-intel.git nncf sentence_transformers einops timm==1.0.22
sentencepiece
When RUN_TESTS=1, prepare_llm_models.sh is called from Dockerfile.redhat with a "docker" argument around line 326. This makes the test environment unstable as it can change day to day as upstream commits new patches to optimum-intel. The reason I worry about this is there is a tight dependency loop around optimum-intel, transformers, nncf, and openvino.
The solution is to pin optimum-intel to a release if at all possible or a commit hash if that doesn't work. Ideally there should be a common requirements.txt that defines what versions of things are in the test environment for validation and the same file used for the base requirements of the python demos.
On the 2026.1 release, the demos/python-demos/requirements.txt has the following lines:
optimum-intel@git+https://github.com/huggingface/optimum-intel.git
That means it builds the wheel at HEAD on main. This is not good for reproducibility. The same issue can be found in prepare_llm_models.sh, at line 48 is:
python3 -m pip install "optimum-intel"@git+https://github.com/huggingface/
optimum-intel.git nncf sentence_transformers einops timm==1.0.22
sentencepiece
When RUN_TESTS=1, prepare_llm_models.sh is called from Dockerfile.redhat with a "docker" argument around line 326. This makes the test environment unstable as it can change day to day as upstream commits new patches to optimum-intel. The reason I worry about this is there is a tight dependency loop around optimum-intel, transformers, nncf, and openvino.
The solution is to pin optimum-intel to a release if at all possible or a commit hash if that doesn't work. Ideally there should be a common requirements.txt that defines what versions of things are in the test environment for validation and the same file used for the base requirements of the python demos.