Poetry: About environment mangement and .venv folder

[azdkj532]

• [x] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

I found that poetry prefer using .venv folder inside as the virtual environment of project. But this behavior is not described in doc. I think it will be good to write down this.

[finswimmer]

Hello @azdkj532,

this is definitly not the default behaviour. I guess you have set in in your config, either global or local, sometime before :)

fin swimmer

[etijskens]

I am surprised by the answer of fin swimmer
this is my config.

poetry config --list
cache-dir = "/Users/etijskens/Library/Caches/pypoetry"
virtualenvs.create = true
virtualenvs.in-project = true
virtualenvs.path = "{cache-dir}/virtualenvs" # /Users/etijskens/Library/Caches/pypoetry/virtualenvs
I see no reference that '.venv' is the default name...

[azdkj532]

@finswimmer Could you have a look on this ? May it's a bug.

~/Workspace/plurkcore(master ✗) poetry env info

Virtualenv
Python:         2.7.17
Implementation: CPython
Path:           /home/larry/.cache/pypoetry/virtualenvs/plurkcore-xdkz89K8-py2.7
Valid:          True

System
Platform: linux
OS:       posix
Python:   /home/larry/.pyenv/versions/2.7.17
~/Workspace/plurkcore(master ✗) virtualenv .venv
New python executable in /home/larry/Workspace/plurkcore/.venv/bin/python2.7
Also creating executable in /home/larry/Workspace/plurkcore/.venv/bin/python
Installing setuptools, pip, wheel...
done.
~/Workspace/plurkcore(master ✗) poetry env info

Virtualenv
Python:         2.7.17
Implementation: CPython
Path:           /home/larry/Workspace/plurkcore/.venv
Valid:          True

System
Platform: linux
OS:       posix
Python:   /home/larry/.pyenv/versions/2.7.17

~/Workspace/plurkcore(master ✗) poetry config --list
cache-dir = "/home/larry/.cache/pypoetry"
virtualenvs.create = true
virtualenvs.in-project = false
virtualenvs.path = "{cache-dir}/virtualenvs"  # /home/larry/.cache/pypoetry/virtualenvs

[azdkj532]

It seems that it doesn't respect the configuration.

[finswimmer]

@etijskens: You have virtualenvs.in-project = true in your config. poetry then creates the venv within the project and calls the folder .venv. The name is hardcoded.

@azdkj532: Ah, I see now. I guess this is a bug. If virtualenvs.in-project = false is set, poetry shouldn't look for .venv within the project folder.

Reopen this issue.

Thanks for reporting!

fin swimmer

[etijskens]

@finswimmer: thanks for the clarification. So the virtual environment name can only be defined by the user for non-local environments... which I guess is not documented.

[frostming]

When virtualenvs.in-project = true poetry will create venv inside .venv folder, but if there is already a .venv there poetry can also show it in poetry env info, even if virtualenvs.in-project = false. I think it is what user expect when the use poetry to manage old project with a local .venv folder. We can make the directory name configurable though.

[finswimmer]

The more I think about the issue, the less I'm sure that it is a bug. Maybe it's the intended behavior and needs to get documentated as you said @azdkj532. Let's see what @sdispater said.

[azdkj532]

@frostming Now .venv directly replaces existed virtual environment instead of just appending to environment list. Before useing command poetry env use ... to select their environment, it's OK to use .venv by default. But current behavior causes distress to user while .venv is activated automatically and didn't appear in poetry env list .

IMO, this feature could be changed into

1. Append .venv into poetry env list automatically.
   1.1 Activate it if the list contains no any other env.
2. Become one of envs that can be either activated or deactivated by poetry env use ...

[azdkj532]

Additional information: Poetry use .venv even it's invalid.

larry@squirrelmac /tmp/project$ poetry env info                                                                                                                           130 ↵

Virtualenv
Python:         3.7.1
Implementation: CPython
Path:           NA

System
Platform: darwin
OS:       posix
Python:   /Users/larry/.pyenv/versions/3.7.1/Python.framework/Versions/3.7
larry@squirrelmac /tmp/project$ mkdir .venv
larry@squirrelmac /tmp/project$ poetry env info

Virtualenv
Python:         3.7.1
Implementation: CPython
Path:           /private/tmp/project/.venv
Valid:          False

System
Platform: darwin
OS:       posix
Python:   /Users/larry/.pyenv/versions/3.7.1/Python.framework/Versions/3.7
larry@squirrelmac /tmp/project$ poetry env use 3.7
Creating virtualenv test-FIFGH_JX-py3.7 in /Users/larry/Library/Caches/pypoetry/virtualenvs
Using virtualenv: /private/tmp/project/.venv
larry@squirrelmac /tmp/project$ poetry env info

Virtualenv
Python:         3.7.1
Implementation: CPython
Path:           /private/tmp/project/.venv
Valid:          False

System
Platform: darwin
OS:       posix
Python:   /Users/larry/.pyenv/versions/3.7.1/Python.framework/Versions/3.7

[lvkswrks]

Hi,
copying over, what I wrote in #967:

I had the expectations, that if virtualenvs.in-project false and virtualenvs.path set to a path, poetry would ignore the in project .venv folder. Treating local .venv differently is imho surprising in this scenario.

The use case we have:

• local development on e.g. OSX with virtualenvs.in-project=true
• server / execution environment in a Docker with virtualenvs.in-project=false and virtualenvs.path=/venv
• execute local code in the Docker by mounting the source code from the local host into the docker

Right now, we work around this issue by exporting the VIRTUAL_ENV=/venv/path/to/bin/python and rm /venv/envs.toml.

[lietu]

Same issue here. I've got a Windows development machine, but code running in Docker with a mount. The local .venv includes Windows binaries etc., and even with virtualenvs.in-project false and virtualenvs.path configured, poetry keeps complaining about The virtual environment found in /project/mount/.venv seems to be broken. and then tries to recreate the env.

Really counter-intuitive behavior.

[sdispater]

I agree that this is not an intuitive behavior.

I think we should make a distinction between the virtualenvs.in-project setting is not set (and keep the current behavior of using the local .venv virtual environment in this case) and if it's set explicitly to False.

That way, we make sure that it's possible to tell Poetry to not use the .venv virtual environment.