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.

[Vigilans]

Now with uv venv --relocatable, the last obstacle to a copiable virtual environment is base python's installation dir: python executable symlink's path and home field in pyvenv.cfg.

I attempted to address it in commit b79ab01, to use relative path for python symlink and home field, when uv venv is provided with:

• Relocatable mode: --relocatable
• A relative path to python installation: --python <../relative/path/to/python>

The python executable does not bring issue, however home in pyvenv.cfg does: when home path is relative, it is relative to python process's working directory, instead of the location of pyvenv.cfg, see python/cpython#83650.

This is essentially a deal breaker. One workaround proposed in Stack Overflow suggests to modify bin/activate script to update home field when activating the environment. This may work in most circumstances, but cannot be proposed as a general solution for uv. I wonder whether home field here will still be an issue when implementing the feature in this issue.