FYI

I would submit a PR but it isn't clear to me which versions need to be pinned for the above mentioned components. Hence submitting an issue without a PR.

Pin torch and associated components' versions

Description

While requirements.txt's content pins specific library versions, Vigil's Dockerfile pip execution on line 42 does not pin specific versions to torch and associated components. More details on the afflicted file & line of code at https://github.com/deadbits/vigil-llm/blob/d53774ca771ff95418d3da4a08d6039c2883f992/Dockerfile#L42C2-L42C112



When you don't version pin, you're not forcing the docker build to verify it has a specific version and thus the required packages you need. This can have unexpected behavior if we install a different version than what we originally installed when we created the Dockerfile. In addition, this technique can also reduce failures due to unanticipated changes in required packages.

Steps to Reproduce

1. Follow the build steps as outlined in the docs's Docker README.md to build and run the afflicted Dockerfile configuration.

Expected Behavior for example given the above FYI

RUN     && pip install --no-cache-dir torch==2.1.1 torchvision==0.16.0 torchaudio==2.1.0 --index-url https://download.pytorch.org/whl/cpu

Actual Behavior

RUN pip install --no-cache-dir torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu .  As a result, my build cache results in sub-optimal behaviors when handling changes in the required packages.

Possible Fix

By pinning the version of torch and associated components, the docker build is forced to retrieve the particular version regardless of what may be in the Docker layer cache.

My Environment

• Project Version: 0.8.7
• Operating System: Container - Linux
• Browser: N/A
• Other Software: Docker, Python, Pip, Torch

Additional Context

• You can also specify the requirements in a text file and pass it to pip as shown at https://note.nkmk.me/en/python-pip-install-requirements/
• More details on why Docker states this is a best practice more than a best effort technique - https://docs.docker.com/develop/develop-images/dockerfile_best-practices/