poetry env remove removes wrong environment

[KDMichaelis]

• I am on the latest Poetry version.
• I have searched the issues of this repo and believe that this is not a duplicate.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: Ubuntu 20.04
• Poetry version: 1.1.14

Issue

I created two poetry environments, project-tmp-1BotOSEK-py3.9 and tmp-project-yuY8E-Dp-py3.9. In my project only the first one is available and activated:

$ poetry env list
project-tmp-1BotOSEK-py3.9 (Activated)

I am trying to delete the other environment using the absolute path according to the documentation as follows:

$ poetry env remove /home/user/.cache/pypoetry/virtualenvs/tmp-project-yuY8E-Dp-py3.9/bin/python

However, this deletes the wrong environment (the activated one) instead:

Deleted virtualenv: /home/user/.cache/pypoetry/virtualenvs/project-tmp-1BotOSEK-py3.9

I would expect that using the absolute path exactly the specified environment would be deleted instead of the activated one, including any data connected to it (e.g. the entry in envs.toml). It actually seems that the entry for the correct (specified) environment was deleted but the wrong (activated) environment is erased instead, leading to inconsistent information in envs.toml.
If for some reason it is desired that a virtualenv cannot be deleted from a project where it's not available (or while another one is activated) the command should at least fail when trying to do so.
As a side note, I am using direnv and the command layout_poetry defined in ~/.direnvrc and called in .envrc within my project.

[dhvcc]

Are there any steps to reproduce this? I imagine renaming your directory/project and creating a new venv?

[KDMichaelis]

I assume it should work with any two environments as long as one is activated but you're trying to delete another one. However, this is how I reproduced it. I used direnv but it should be easy to reproduce another way as long as the virtualenvs are activated accordingly.

mkdir ~/work/example-one ~/work/example-two
touch ~/work/example-one/.envrc ~/work/example-two/.envrc

cd ~/work/example-one
poetry init
poetry run true

This should have created the virtualenv for example-one.
Use default arguments where possible and don't define dependencies in poetry init.
Copy the following lines into the .envrc (replace the hardcoded virtualenv path with the path you received with poetry run true):

export VIRTUAL_ENV="/home/user/.cache/pypoetry/virtualenvs/example-one-qghPbawY-py3.9"
export PATH="${VIRTUAL_ENV}/bin:${PATH}"

Then activate the env variables:
direnv allow

3. Repeat step 2 for example-two
4. So now in both folders the respective environment should be active.

cd ~/work/example-two
poetry env remove /home/user/.cache/pypoetry/virtualenvs/example-one-qghPbawY-py3.9/bin/python

(Again, replace the path with your path of the virtualenv for example-one).

And for me this yields:
Deleted virtualenv: /home/user/.cache/pypoetry/virtualenvs/example-two-fDNNumlZ-py3.9

[dhvcc]

@python-poetry/triage
Hi, I'd like to take on this issue. The solution is pretty easy - just to extract real venv path with something like that import sys; print(sys.prefix) and removing it instead of always generating venv name from current project.

This issue is easily reproducable:

1. Create a dir mkdir dir_name and run poetry init & poetry install (remember this venv's path)
2. Go back cd .. and rename this directory mv dir_name dir_name_renamed
3. Run poetry install, which will create new venv, and then run poetry env remove with old venv's path. Poetry will try to remove current venv, not an old one.
   This also works for venv not for this project.

Even if the solution is simple I'd still need to understand other code, which is not very clear without comments. We still need to understand whether this feature is simply missing or other code is not working as expected. So, if anybody knows something about this feature - It'd be nice to hear from you.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.