Support copy or hardlink python interpreter when creating venv

[amartani]

Currently, when creating a venv, uv always symlinks the python interpreter. Example:

$ uv venv --python=3.12 /venv
$ ls -l /venv/bin
...
lrwxrwxrwx 1 root root   25 Aug 28 23:53 python -> /root/.local/share/uv/python/cpython-3.12.5-linux-aarch64-gnu/bin/python3.12
lrwxrwxrwx 1 root root    6 Aug 28 23:53 python3 -> python
lrwxrwxrwx 1 root root    6 Aug 28 23:53 python3.12 -> python

The original python -m venv supports either symlink or copy (with --symlinks / --copies flag). It would be great if uv also supported the same, similar to how --link-mode exists for uv pip.

My main use case is for using a docker multi-stage build where one of the stages builds the venv and then other stages can just copy the entire venv folder; example Dockerfile:

FROM base as venv-builder

RUN uv venv --python=3.12 /venv
RUN uv pip install --python /venv/bin/python ...

FROM base as final-image

# Do other things here

COPY --from=venv-builder /venv /venv

This use case currently breaks as the symlink ends up pointing to a python binary that does not exist in the final image. For this use case, the ideal behavior would be that the main /venv/bin/python binary was copied or hardlinked from the external binary and python3/python3.12 continued to be relative symlinks.

Tested on uv version 0.4.0.

[charliermarsh]

This makes sense to me.

[zanieb]

Minor note, this is included as --bundle-python in @konstin's document about features we should add for Docker.

[SethWen]

Sometimes, I want to package the Python source code and the virtual environment (venv) together for direct distribution. In this case, the interpreter should not be a symbolic link, but a full copy of the original interpreter. and I hope to have an option for this.
Currently, I am using a mix of conda and pip. After this feature is added in the future, I plan to replace them with uv.

[mweislley]

Running into this also - basically the docker case but the applications current make use of python -m venv .bundle --copies and I'm not seeing any alternative apart from this issue.

[charliermarsh]

I think the alternative is you just copy over the interpreter along with the environment.

[RayyanRiaz]

any updates here? Would really like to have this functionality!

[MarijkeStein]

Me as well, please 💟

We use the official Docker images to setup Python environments with 'uv'.

But later on, we need to run the actual scripts under a different Docker image.

The way with having a combined image (donor 'uv' executable) does not really scale, as you would need to build one image per combination of Python interpreter version and Linux distro 🙈 .

[bennyweise]

+1 for this, for a different use case. Using uv virtual environments with Cursor, Cursor appears to follow the symlink and give me the wrong environment. I'm also following up to see if it's something I can fix within Cursor, but I've had no luck so far.

[kaytwo]

+1 for this, for a different use case. Using uv virtual environments with Cursor, Cursor appears to follow the symlink and give me the wrong environment. I'm also following up to see if it's something I can fix within Cursor, but I've had no luck so far.

Same in vscode, at least for me.