Poetry continues to use existing virtualenv after virtualenvs.create is set to false

[tomjorquera]

• 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: Debian 5.4.8-1 (sid)

• Poetry version: 1.0.2 (installed via pip)

• Link of a Gist with the contents of your pyproject.toml file: N/A

Issue

I noticed that if I first use poetry with a virtualenv for a project, then set virtualenvs.create to false, poetry will continue to use the virtualenv, but poetry env info will imply otherwise.

To reproduce:

1. create new project (with default config, aka venvs enabled)

> poetry new test -n; cd test; poetry install; poetry env info

Virtualenv
Python:         3.6.8
Implementation: CPython
Path:           /home/tom/.cache/pypoetry/virtualenvs/test-leE_QmNr-py3.6
Valid:          True

System
Platform: linux
OS:       posix
Python:   /home/tom/.pyenv/versions/3.6.8
 test 

So far so good

2. Set virtualenvs.create to false

> poetry config virtualenvs.create false; poetry env info

Virtualenv
Python:         3.6.8
Implementation: CPython
Path:           NA

System
Platform: linux
OS:       posix
Python:   /home/tom/.pyenv/versions/3.6.8

Poetry seems to have "forgotten" the venv. However...

3. Try to use without the venv

> poetry install
Installing dependencies from lock file

No dependencies to install or update

  - Installing test (0.1.0)

Poetry is still considering everything to be up-to-date! (and does not mention "Skipping virtualenv creation, as specified in config file.")

> poetry shell
Spawning shell within /home/tom/.cache/pypoetry/virtualenvs/test-leE_QmNr-py3.6

(test-leE_QmNr-py3.6) >

And trying to run a shell still put me into the venv.

Observations

If I now create a new project, everything works as expected and poetry will not use a venv for it. But the old project continues to use the existing venv, despite poetry env info implying otherwise.

I get that the doc for virtualenvs.create says "Create a new virtual environment if one doesn't already exist", so this behavior may be deemed to be correct. But:

• it seems a little counter-intuitive (to me at least)
• poetry env info seems to give misleading information (or did I misunderstood?)
• it can lead to weird unexpected behavior in specific situations (see context below)

If the behavior of virtualenvs.create is to be kept unchanged (I guess it could cause some backward compatibility issues otherwise), I would suggest providing another configuration option, e.g. virtualenvs.disable, to give the possibility of disabling venvs altogether (for example to use in CI, or possibly inside docker images I guess... see context below).

---

For context, I discovered the bug after being bitten by it while configuring poetry for CI. I first configured poetry to use a venv and (mistakenly) added it to the cache. Afterward I changed the CI by configuring poetry to not create a venv. But due to this behavior it kept using the cached venv on subsequent runs, causing some head-scratching.

Only after cleaning the CI cache did poetry start to behave as expected.

[jacek-jablonski]

Same on my side.

In docker I tend to use virtualenvs.create set to false, whereas on my system I use virtualenvs.create set to true and virtualenvs.in-project set to true.
Poetry inside docker keeps using and overwriting my local .venv dir.

[relu]

For anyone else trying to find a workaround, seems setting the environment variable POETRY_VIRTUALENVS_CREATE=false does the trick. I actually think this is a better option since it can be set globally in the Dockerfile :)

[finswimmer]

Hello,

setting virtualenvs.create means "Don't create a venv". It does not mean "Don't use a venv if one exists". So if an venv already exists Poetry will use it, even if virtualenvs.create is set to false.

The issue in the OP, that poetry env info doesn't show up the venv after changing the config, seems to be fixed (testet with 1.2.0b2).

fin swimmer

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