Signed-off-by: Jaideep Rao <[email protected]>
(cherry picked from commit 8ea9979)

For instructlab, "pip install ." does not install vllm, but it does
install an uncapped torch (2.7.0 currently).

When we install vllm later, we compile a binary flash_attn wheel against
torch 2.7.0. vllm 0.8.4 requires torch==2.6.0, so we downgrade torch,
and then we use that with the incompatible flash_attn binary wheel.

To resolve this, use constraints-dev.txt in the first pip install
operation. This restricts torch to 2.6.0 immediately when we first
install instructlab, so that we will compile flash_attn against that
torch version.

Signed-off-by: Ken Dreyer <[email protected]>
(cherry picked from commit 8a11c90)

# Conflicts:
#	.github/workflows/e2e-nvidia-l40s-x4-py312.yml

…-3320

use `constraints-dev.txt` in e2e tests (backport #3320)

Newer versions of Docling can raise an exception during custom garbage
collection code of TesseractOcrModel that nothing ever catches,
because exceptions during garbage collection are generally not caught
by anything. The exception is harmless to any of our InstructLab
use-cases, and only happens when the TesseractOcrModel was not able to
construct itself anyway, which we check for and handle to fallback to
EasyOCR or other implementations.

However, py3-unitcov by default fails the test suite if any of these
unraisable exceptions happen. This adjusts that to not fail the test
suite. Messages still get logged about the exception during regular
py3-unit testing, so we can see when this gets fixed in Docling, but
there's no need for it to actually fail our test suite.

Signed-off-by: Ben Browning <[email protected]>
(cherry picked from commit 65c1efb)