Basically a way to uninstall the corresponding virtualenv easily.
Not yet, no. Just playing devil's advocate, how would that be useful?
I've also seen the suggestion of being able to print the virtual environment's path. Maybe a poetry env command could be created to handle these?
It's useful for easily cleaning out deps when you no longer need a copy of them. I often clone a project to modify some code and test out the changes, but afterwards I don't need the virtualenv since I'm finished patching it. I've also cloned multiple copies of a project so I can work on one copy while a long running job is running on the other, and I don't want deps taking up disk space once I'm done.
I implemented it just for fun: https://github.com/cauebs/poetry/commit/1dc35a2d1bedadebcc55c5871278fe8cf01ef6a5
But for this we'll really need @sdispater's input, because I fear we're adding too many commands and duplicating features.
The other simple solution is an alias or a script; since I pull those down to all systems I use anyway.
I've been using the following:
rm -rf "$(dirname "$(dirname "$(poetry run which python)")")"
Note that the failure mode (for running outside of a poetry environment) is to run rm -rf . but rm will refuse to remove the current directory, so it should be relatively safe.
Edited to add:
It would perhaps make sense to be able to find all poetry environments whose project definitions no longer exist, but the metadata isn't there for that case; it would allow having a user cron job to periodically cleanup never-to-be-used-again virtualenvs.
This is supported in the 1.0.0 prereleases. See #731
Most helpful comment
It's useful for easily cleaning out deps when you no longer need a copy of them. I often clone a project to modify some code and test out the changes, but afterwards I don't need the virtualenv since I'm finished patching it. I've also cloned multiple copies of a project so I can work on one copy while a long running job is running on the other, and I don't want deps taking up disk space once I'm done.