uv
uv copied to clipboard
`uv venv` overwrites existing virtual environment on subsequent run
Current behaviour: subsequent runs of uv venv overwrite the existing virtual environment.
Suggested behaviour: How about adding a prompt like "the virtual env is already created, confirm to recreate from scratch".
Thanks for the report, related https://github.com/astral-sh/uv/issues/1274
I don't think we should delete them by default cc @charliermarsh
For reference, the upstream virtualenv has a --clear flag, and when that's not set it will update the virtual environment and the seeded packages, but without touching anything else. This way, running without a --clear is essentially a repair option.
So, what do you think on the UX of this command? For me it also seems unintuitive when I am using uv venv and the existing env is overwritten with an empty one.
I propose a simple thing, like adding a --clear flag for uv venv command. if there is an existing venv and the flag is not set, then we simply do nothing. In other cases we preserve the old behaviour. What do you think?
@flyaroundme that would definitely be a much less surprising behavior. Good suggestion!
if there is an existing venv and the flag is not set, then we simply do nothing.
I'd imagine a better UX would be to fail hard and loud.
+1 on "fail hard and loud" to avoid ambiguity - but then I believe uv venv should support both "force keep" and "force clean" workflows. F.x. I have been happily using python -m venv for the last few years somewhat like this:
# run `source ./project.sh` to get the project and environment for it up and running
export SOMETHING=something
python -m venv
source ./venv/bin/activate
python -m pip install -e .[dev]
, keeping the project and its deps in sync - but not wiping any additional tools if I have put there for some experiments. Yet I can easily imagine that one would like to wipe the existing venv instead.
Lots of ux discussion in https://github.com/astral-sh/uv/pull/2548