uv venv still overwrites existing venv in various cases

[matterhorn103]

I found many related threads (#2548, #1777, #1472) so it's not even really a new issue, but from what I can gather it was meant to no longer be the case that existing venvs get overwritten, while for me they still do.

e.g.

>>> uv venv foo --verbose
DEBUG Searching for Python interpreter in search path
DEBUG Found CPython 3.11.9 at `/usr/bin/python3` (search path)
Using Python 3.11.9 interpreter at: /usr/bin/python3
Creating virtualenv at: foo
Activate with: source foo/bin/activate
>>> source foo/bin/activate.fish
(foo) >>> uv pip install tomli_w
Resolved 1 package in 65ms
Installed 1 package in 1ms
 + tomli-w==1.0.0
(foo) >>> deactivate
>>> uv venv foo
DEBUG Searching for Python interpreter in search path
DEBUG Found CPython 3.11.9 at `/usr/bin/python3` (search path)
Using Python 3.11.9 interpreter at: /usr/bin/python3
Creating virtualenv at: foo
INFO Removing existing directory
Activate with: source foo/bin/activate
>>> source foo/bin/activate.fish
(foo) >>> uv pip list
(foo) >>>

The result is the same if just uv venv is executed with no name, and the result is also the same if uv venv foo is executed within foo without deactivating.

uv venv foo --allow-existing correctly keeps any packages installed in the venv. However, if a different Python interpreter is used (not necessarily deliberately), the effect is still that of overwriting:

>>> uv venv foo --verbose -p 3.12
DEBUG Searching for Python 3.12 in search path
DEBUG Found CPython 3.12.3 at `/usr/bin/python3.12` (search path)
Using Python 3.12.3 interpreter at: /usr/bin/python3.12
Creating virtualenv at: foo
Activate with: source foo/bin/activate
>>> source foo/bin/activate.fish
(foo) >>> uv pip install tomli-w
Resolved 1 package in 49ms
Installed 1 package in 0.80ms
 + tomli-w==1.0.0
(foo) >>> deactivate
>>> uv venv foo --verbose --allow-existing
DEBUG Searching for Python interpreter in search path
DEBUG Found CPython 3.11.9 at `/usr/bin/python3` (search path)
Using Python 3.11.9 interpreter at: /usr/bin/python3
Creating virtualenv at: foo
INFO Allowing existing directory
Activate with: source foo/bin/activate
>>> source foo/bin/activate.fish
(foo) >>> python3 -V
Python 3.11.9
(foo) >>> uv pip list
(foo) >>>

It seems #2548 added the --force flag to overwrite an existing venv. But I don't seem to have the --force flag listed for uv venv -h or uv run -h. I'm aware the UI is still very much in flux, so this isn't in any way a complaint, I just want to make sure you are aware that this is how things are working at the moment.

This is uv version 0.2.11 on Linux.

[zanieb]

Hi! We've actually never changed this. We'll always overwrite a typical existing environment (without opt-in) unless it has some extraneous files we do not recognize in which case we require the --allow-existing flag to create a virtual environment and ignore those files. We renamed the flag from --force to attempt to clarify this (#3416).

[charliermarsh]

Yeah this is still intentional -- can we merge with #1472?

[zanieb]

Sorry I guess --allow-existing is more broad than I originally understood, but I do think that's reasonable behavior given the flag. If you want to remove packages, we need a --clear option as discussed in the linked issues.

[matterhorn103]

Hi! We've actually never changed this. We'll always overwrite a typical existing environment (without opt-in) unless it has some extraneous files we do not recognize in which case we require the --allow-existing flag to create a virtual environment and ignore those files. We renamed the flag from --force to attempt to clarify this (#3416).

Ah ok, sorry, I missed that particular PR. And I also misinterpreted --allow-existing as meaning "if a venv exists, allow it to stay" rather than "allow overwrite of an existing venv". Particularly as I understood the first line of the docs:

  --allow-existing
          Preserve any existing files or directories at the target path.

to mean that any existing .venv directory and its contents would be preserved. The next paragraph makes it clear, but I didn't read that far.

Yeah this is still intentional -- can we merge with #1472?

Fair enough, sorry for misunderstanding! The merge is obviously fine by me

[zanieb]

@T-256 I think

will instead write to the given path, regardless of its contents, and without clearing it beforehand.

is pretty explicit that it won't be cleared. Why would you expect this to remove packages?

@matterhorn103 are there other documentation changes you'd find helpful here?

[charliermarsh]

(Closing as I think this is working as intended modulo the decisions to be made in those open issues.)