Llama Stack should help users pick a correct Python interpreter

[JamesKunstle]

🚀 Describe the new functionality needed

LLS uses uv as the package manager for venv image builds. By default, uv uses the default system installation of Python (/usr/bin/python) even when uv is itself installed in a virtual environment. i.e. the following can happen:

$ python3 --version # 3.9.19
$ (venv) python3 --version   # 3.11.11
$ (venv) pip3 install uv
$ (venv) uv venv venv-new
Using CPython 3.9.19 interpreter at: /usr/bin/python
Creating virtual environment at: venv3
Activate with: source venv-new/bin/activate

This makes sense because if uv is creating a new virtual environment, it shouldn't use the same python interpreter that it's running with. It should use a sensible default, and the system Python is usually OK.

However, LLS requires Python>=3.10 and doesn't tell the user why it's attempting to use the system python when it (llama-stack) is installed in a virtual environment with a Python interpreter that satisfies that requirement.

$ (venv) python3 --version   # Python 3.11.11
$ (venv) llama stack build --template ollama --image-type venv
Environment 'llamastack-None' already exists, re-using it.
Using virtual environment llamastack-None
Using CPython 3.9.19 interpreter at: /usr/bin/python
Creating virtual environment at: llamastack-None
Activate with: source llamastack-None/bin/activate
Using Python 3.9.19 environment at: /usr
  × No solution found when resolving dependencies:
  ╰─▶ Because the current Python version (3.9.19) does not satisfy
      Python>=3.10 and all versions of llama-stack depend on Python>=3.10, we
      can conclude that all versions of llama-stack cannot be used.
      And because you require llama-stack, we can conclude that your
      requirements are unsatisfiable.
Failed to build target None with return code 1

There's a very easy solution for this: uv provides an environment variable export UV_PYTHON that'll override the default system Python.

$ (venv) UV_PYTHON=$(which python3) llama stack build --template ollama --image-type venv
Environment 'llamastack-None' already exists, re-using it.
Using virtual environment llamastack-None
Using CPython 3.11.11 interpreter at: venv/bin/python3
Creating virtual environment at: llamastack-None
Activate with: source llamastack-None/bin/activate
Using Python 3.11.11 environment at: venv
Audited 1 package in 44ms
Installing pip dependencies
Using Python 3.11.11 environment at: venv
Audited 32 packages in 11ms
torch torchvision --index-url https://download.pytorch.org/whl/cpu
Using Python 3.11.11 environment at: venv
Audited 2 packages in 3ms
sentence-transformers --no-deps
Using Python 3.11.11 environment at: venv
Audited 1 package in 5ms
Build Successful!

A less-than-ideal problem is that if one tries to use the same interpreter but in the global context (/usr/bin/python3.11) there are permission errors:

$ (venv) UV_PYTHON=/usr/bin/python3.11 llama stack build --template ollama --image-type venv
Environment 'llamastack-None' already exists, re-using it.
Using virtual environment llamastack-None
Using CPython 3.11.11 interpreter at: /usr/bin/python3.11
Creating virtual environment at: llamastack-None
Activate with: source llamastack-None/bin/activate
Using Python 3.11.11 environment at: /usr
Resolved 55 packages in 789ms
      Built fire==0.7.0
Prepared 54 packages in 736ms
error: Failed to install: typing_extensions-4.12.2-py3-none-any.whl (typing-extensions==4.12.2)
  Caused by: failed to create directory `/usr/local/lib/python3.11/site-packages/`: Permission denied (os error 13)
Failed to build target None with return code 2

Feature request

LLS should detect that a user is trying to use an out-of-date python interpreter before attempting to create / install dependencies in a virtual environment and tell them that they can override the interpreter via the environment variables. The internal build script doesn't allow for uv venv --python ... overriding, so this would be the next best thing.

💡 Why is this needed? What if we don't build it?

This was a confusing error with a very quick solution. To know how to solve the error (i.e. telling uv which interpreter it needs to use) one has to dig through the build scripts to know which package manager is being used and whether it'll allow specifying a Python interpreter in-situ. It'd be easier to just check for the user ahead of time during the dependency installation process.

Other thoughts

No response