'venv --clear' should prompt user before nuking entire directory

[alimpfard]

BPO	46326
Nosy	@vsajip, @eryksun, @alimpfard

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-01-10.09:01:46.744>
labels = ['type-bug']
title = "'venv --clear' should prompt user before nuking entire directory"
updated_at = <Date 2022-01-13.15:29:41.064>
user = 'https://github.com/alimpfard'

bugs.python.org fields:

activity = <Date 2022-01-13.15:29:41.064>
actor = 'ned.deily'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2022-01-10.09:01:46.744>
creator = 'alimpfard'
dependencies = []
files = []
hgrepos = []
issue_num = 46326
keywords = []
message_count = 6.0
messages = ['410192', '410223', '410228', '410229', '410230', '410282']
nosy_count = 3.0
nosy_names = ['vinay.sajip', 'eryksun', 'alimpfard']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46326'
versions = []

[alimpfard]

virtualenv --clear is extremely eager to delete the passed directory without
any sort of confirmation, leading to possible data-loss
(e.g. with a mistyped command, or a misunderstanding of what it actually does).

Simply deleting an entire directory tree with a command that's extremely
prone to misunderstanding should not be virtualenv's job, but as it has
decided to make this its job, then it should take proper precautions to avoid
unintentional rm -fr some-directory by at least asking for confirmation.
The previous behaviour can of course, stay behind a --force flag for uses in
CI or similar, but this should not be the default behaviour.

related: pypa/virtualenv#1890 mentions that
"[it is not] good practice to put non-virtual environment-related files into a
virtual environment", which is sensible, and so virtualenv should then simply
refuse to be instantiated in a non-empty directory.

On a more subjetive note, virtualenv --clear <dir> sounds like a way to purge the virtual environment files from a directory (yes, I understand what the help says, but that hardly changes anything), so perhaps a more verbose flag like "--clear-contents" would be more appropriate, but I digress.

[ned-deily]

It appears you are describing behavior in the third-party virtualenv project; if so, you should report the problem to that project (https://pypi.org/project/virtualenv/). If similar behavior is also an issue with the Python standard library venv module (which is a derivative of virtualenv), please update this issue accordingly. Thanks!

https://docs.python.org/3/library/venv.html

[eryksun]

Ned, the CLI of venv has a --clear option, which invokes EnvBuilder [1] with clear=True. It's implemented by EnvBuilder.clear_directory(). Ali wants this method to prompt for confirmation before deleting the directory contents and also proposes the addition of a new --force option to skip the prompt.

---
[1] https://docs.python.org/3/library/venv.html#api

[ned-deily]

Ned, the CLI of venv has a --clear option, which invokes EnvBuilder [1] with clear=True.

Thanks, I saw that. However, the issue as written does not mention venv at all, only virtualenv. I wanted the OP to verify that it does apply to venv and, if the problem exists both places, to update this issue and to open an issue against virtualenv.

[eryksun]

The implementation of --clear in virtualenv apparently was changed to align with venv. On the linked virtualenv issue, Bernát Gábor suggested creating a bpo issue for venv to determine how the issue should be resolved for virtualenv.

[alimpfard]

If similar behavior is also an issue with the Python standard library venv module (which is a derivative of virtualenv), please update this issue accordingly

Yes, my bad, I should have mentioned that this applies to venv, I will update the issue title.

Not sure if I can modify my earlier comment however (I don't see any way to).

[vsajip]

I think venvs should be seen as disposable, and easily recreatable using e.g. pip install -r requirements.txt. What's the reason why this can't be done on the odd occasion when a venv is cleared out unintentionally? The help for this option is pretty unambiguous.

[crides]

was messing with venv, and now my (fortunately termux) $HOME is gone.

The help for the venv cli says:

positional arguments:
  ENV_DIR               A directory to create the environment in.

which means it should be perfectly fine to pass . or any existing directory as ENV_DIR, and same for --clear as well. You can say it's the user's (my) fault of not understanding what venv does, but also seems the help also doesn't say what it does clearly.