Why would that be the case in this example? We explicitly use Python 3.12 bookworm-slim for both stages.

the first stage uses uv to build the venv. the default config for uv is to manage the python interpreter which means it will download a fresh one instead of using the installed system interpreter
after copying the venv to the second stage without the managed interpreter, the venv python symbolic link is pointing to a non existent interpreter (the managed one from the first stage)

hope that makes it more clear

the first stage uses uv to build the venv. the default config for uv is to manage the python interpreter which means it will download a fresh one instead of using the installed system interprete

Except, by default, uv will not manage the Python interpreter if it can find one that satisfies your project's required version.

I suggest adding to multistage example: (or some other check or warning)

COPY --from=builder --chown=app:app /app /app
# Test if python link is not broken.
# If this fails check that image python version satisfies your project requirement version
RUN test -e /app/.venv/bin/python

I spent a bit of time to figure out what's wrong with my simple test project before noticing that link was broken because image python version was too low. (this test fails in that scenario and works in good one)

Or using --no-python-downloads (UV_PYTHON_DOWNLOADS=0) option with uv in the first stage - that also catches my issue.

Hm maybe... it's already called out explicitly

Disabling downloads seems fine too, but.. you can use downloads you just should copy the interpreter across to the second stage as well.

the first stage uses uv to build the venv. the default config for uv is to manage the python interpreter which means it will download a fresh one instead of using the installed system interprete

Except, by default, uv will not manage the Python interpreter if it can find one that satisfies your project's required version.

for me even though the requires-python is set to >=3.12 uv still downloads a managed version. it's a workspace setup so it might be related (all the pyproject.toml files specify the same requires-python)

anyway in my opinion in this case(CI) it's better to be explicit about which interpreter to use instead of relying on implicit behaviour

Disabled downloads in #42

I think using UV_PYTHON is too confusing for the general example.

Similarly, I'll finish up #15 and merge that