-
Notifications
You must be signed in to change notification settings - Fork 562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow --force
to overwrite existing virtualenv
#2548
Conversation
--force
to overwrite existing virtualenv
208ee71
to
0bab411
Compare
I do make use of |
Before I respond to that, I should note that |
Ah sorry for the ambiguous language, I mean "clear the environment" as-in reset the virtual environment to an initial state not "clear the entire folder". e.g. |
That makes sense. I guess I'm not totally sold on changing the current overwrite behavior... I have a hunch that it's a difference in the API, and that leads to initial confusion, but that it's actually not a bad behavior. |
Relatedly, |
I just can't think of a time when I've ever run |
I think it would happen when you didn't realize that there was an existing environment... which would be bad if you weren't constructing your environment from lockfiles (which is fairly common for people other than us). |
Any updates on this? |
@zanieb @charliermarsh did this get lost? |
I think we just lost steam because it started to get entangled with the discussion around whether we should change the |
And what the flags should be for these various behaviors |
Concretely, I'd be okay with:
I don't see any reason to remove unknown files on |
So would the behavior without any flags change? (Does |
I think the existing behavior should change to fail if |
I don’t understand what clear does then. And clear would then differ from virtualenv despite having the same name. What does it do? Removes specific folders? |
Hence suggesting Isn't what I wrote concrete?
I expect it to remove all the packages and reset the virtual environment files (i.e. that it would create) not delete every file in the directory. |
Not tied to this proposal, just putting something concrete forward so we can make progress on it. |
I think I'm just trying to understand the motivation for keeping some of the content in the virtualenv. When would that be needed? |
I'm not sure, for whatever weird thing is going on in #2529? Perhaps what I'm thinking is... it feels hard for a user to just clear the packages themselves but very easy for a user to delete the whole directory if they want. |
👍
It's useful when an external tool adds its specified files to |
@charliermarsh so yeah once you're in that situation how do you clear the packages from the virtual environment in the folder? |
I don't think they reuse the directory in that way, though. It sounds like they create a new directory, seed it, use it for a virtualenv, then move on. I imagine that they then repeat that entire process when they need a new virtualenv. So, I'm not sure it's worth designing around and supporting that workflow when we don't have a clear motivating use-case. |
I think about it like this: I use |
🤷 IDK, personally I would find it surprising if If we can't agree, then should we at least move forward with |
🤷♀️ okay let's just go forward with both |
I like the current behavior, it encourages treating venvs as ephemeral |
I feel quite strongly that our current behavior is nice for us but doesn't make sense for the average user. Virtual environments are going to be ephemeral and abstract in our future workflows, we don't need to enforce this idea by making it easy to delete your environment when using a plumbing command. |
0bab411
to
8f65128
Compare
Okay, let's proceed with |
CodSpeed Performance ReportMerging #2548 will not alter performanceComparing Summary
|
8f65128
to
da4d103
Compare
CodSpeed Performance ReportMerging #2548 will not alter performanceComparing Summary
|
da4d103
to
540aab1
Compare
CodSpeed Performance ReportMerging #2548 will not alter performanceComparing Summary
|
Summary
Closes #2529.
Test Plan
mkdir .venv
touch .venv/foo
cargo run venv
(ensure failure)cargo run venv --force
(ensure success)cargo run venv --force
(ensure success again)