Creating venvs from uv python installtions creates broken venvs

[Olindholm]

I am using uv to control my python version, great stuff. I create a venv using uv uv venv --python ... and uv will install whatever version I requrest. Works great.

I am also using an internal python package which creates it's own python venv in order to run some commands in isolation. Using regular python this works fine, but when using uv's managed installed pythons it does not work.

I believe I have identified the problem being that the package creates venvs using copy, rather than symlink. The issue can be replicated the following way.

# Create a venv with uv managed version
uv venv --python 3.8
source .venv/bin/activate

# Create a venv using copy
python -m venv .venv2 --copies # This command will yield and error:
Error: Command '['/home/username/.venv2/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 127.

# To understand why this failed, let's run that command ourselves
$ /home/username/.venv2/bin/python -Im ensurepip --upgrade --default-pip # This will also error:
/home/username/.venv2/bin/python: error while loading shared libraries: /home/username/.venv2/bin/../lib/libpython3.8.so.1.0: cannot open shared object file: No such file or directory

Note: Creating your venv using --symlinks flag instead, works great.

As I understand it, when creating venvs using copy, python -m venv --copies or import venv; venv.create(symlinks=False), the python executable is copied, as you'd expect. But uv's python binary is different from regular one, which has links to files which don't get copied. Yielding the venv broken.

[konstin]

This sounds like another case of astral-sh/python-build-standalone#380

[charliermarsh]

uv venv itself doesn't support --copies so in some sense this isn't a uv issue but a python-build-standalone issue.

[zanieb]

Similar to #8821

Note there's not a clear path to solving this upstream unless we want to patch CPython runtime behavior. I think installers of the distributions may need to patch the sysconfig to fix this as described in #8429

[charliermarsh]

Yeah I have no idea how this would work for --copies since we lose all connection to the originating distribution.