uv venv overwrites existing virtual environment on subsequent run

[Slyfest]

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".

[zanieb]

Thanks for the report, related #1274

[zanieb]

I don't think we should delete them by default cc @charliermarsh

[gaborbernat]

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.

[flyaroundme]

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?

[Slyfest]

@flyaroundme that would definitely be a much less surprising behavior. Good suggestion!

[gaborbernat]

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.

[Artalus]

+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.

[zanieb]

Lots of ux discussion in #2548

[verveguy]

uv venv --allow-existing provides the desired behavior - don't recreate the venv every time.

Perhaps the question is whether the sense of the default should be inverted i.e. update existing by default, only replace if --clear is specified.

[janimo]

I find it very unusual for a cli tool to overwrite and existing directory by default, without warning or prompting.

Now I have learned this is the intended behavior, but the number of people reporting being confused by this suggests that some UI change would be helpful.

[zanieb]

I don't love the existing behavior, but, for what it's worth, this issue has about three upvotes and we see an order of magnitude more than that on issues that many people encounter.

[usetheforce]

+100 on "fail hard and loud". Just lost a bunch of files because of this.
uv mimics pip's behaviour in many places, but not here -- where damage can be done really easily? python -m venv leaves any existing files in place (which are not part of the venv-local python).

I mean: what's the win in the current behaviour? Spare one rm -rf *?

uv is no doubt a brilliant tool and I love it. But PLEASE change this.

[kmalinich]

+10000 on fail hard and loud.

Because of this I accidentally grenaded my entire home assistant installation. Now my smart home is borderline useless. No heat, no lights, nothing; I have my whole house in there.

Yes I have backups, but I have to retrieve them and restoring them isn't an immediate process - meanwhile my baby is crying, my wife's pissed, the list goes on.

I've been a Linux engineer for close to a decade, in some high caliber environments - and I think I can count on one hand the times where I used a tool, with only one or two arguments, copied and pasted from the --help usage message, that automatically assumed that I wanted to completely blow away everything in the current directory, and was so confident in it, that it didn't even give me a simple "You sure? [y/N]" .

Maybe I just wanted to share my story, or just vent.. but damn man this one hurt.

[charliermarsh]

@kmalinich -- Hey -- regardless of what decision we make here, just wanted to say that I can feel your frustration coming through and I'm really sorry that you ran into this in such a critical path. A lot for us to consider in your message.

[kmalinich]

@charliermarsh -- I want you to know that your words meant a lot to me. Thank you. I'm all back up and running here, and I've calmed down a fair bit. Sorry about that, that was some pretty explosive messaging on my part.

uv is an awesome tool, and I totally understand that I'm not using it in a way that matches a majority of its users, and that's a big part of what led to my situation occurring. Totally my fault.

Anyways, thanks again for the kind words. It's nice to .. just be heard, sometimes.

[zanieb]

I'm down to change this in 0.5.0 — but we'll need to discuss this as a team and figure out if there's consensus on a new ux.