Poetry: if poetry is installed into a virtualenv, it's installing my project into it too

[mmerickel]

• [X] I am on the latest Poetry version.
• [X] I have searched the issues of this repo and believe that this is not a duplicate.

• [X] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: macOS 10.14

• Poetry version: 0.12.3

Issue

I have installed poetry into a virtualenv, and poetry is using that virtualenv to install my project, despite it not being active. I would expect poetry to make a new virtualenv for this project.

$ python3 -m venv penv
$ penv/bin/pip install poetry
$ penv/bin/poetry install

Note that my project was installed into penv despite it not being activated. It looks like (possibly) https://github.com/sdispater/poetry/commit/fa4c116213557579b1596f2ff0148f7865759ac6 broke things. poetry debug:info displays the virtualenv as the penv that poetry is installed into but my shell has no VIRTUAL_ENV var set.

[bertjwregeer]

Since I prefer to manage my tools using virtualenv's using pip, I have a similar issue:

Riley:account-new xistence$ poetry debug:info

Poetry
======

 * Version: 0.12.3
 * Python:  3.7.0


Virtualenv
==========

 * Python:         3.7.0
 * Implementation: CPython
 * Path:           /Users/xistence/.ve/poetry


System
======

 * Platform: darwin
 * OS:       posix
 * Python:   /Users/xistence/.pyenv/versions/3.7.0

I also use the ~xistence/.ve/poetry/ virtualenv to install beta/git versions of poetry.

I have a virtualenv in the local directory named .venv that was created by poetry 0.11.5, with this setting:

settings.virtualenvs.in-project = true

[bertjwregeer]

This is how version 0.11.5 behaves installed into that same virtualenv:

Riley:account-new xistence$ poetry debug:info

Poetry
======

 * Version: 0.11.5
 * Python:  3.7.0


Virtualenv
==========

 * Python:         3.7.0
 * Implementation: CPython
 * Path:           /Users/xistence/Projects/APPA/account-new/.venv


System
======

 * Platform: darwin
 * OS:       posix

[mmerickel]

I did notice that in_venv is True via https://github.com/sdispater/poetry/commit/fa4c116213557579b1596f2ff0148f7865759ac6#diff-243e95fabbdb8decc022350c12f83633R101 where sys.base_prefix != sys.prefix.

$ penv/bin/python
>>> import sys
>>> sys.base_prefix
'/Users/michael/.pyenv/versions/3.7.0'
>>> sys.prefix
'/Users/michael/work/api-server/penv'

[sdispater]

The thing is there are multiple ways to detect a virtualenv and comparing sys.base_prefix and sys.prefix is one of them. This has been added to fix issues like #392.

Now, I understand that this might be problematic and I am not sure about the best approach here. Either we assume that Poetry is always installed independently and create a virtualenv anyway (unless there is a VIRTUAL_ENV set or Poetry is told otherwise) or keep the current behavior.

[mmerickel]

I can tell you that as a user my expectation was that it only used the VIRTUAL_ENV env var. This is how pipenv works and a lot of other tools I use that are installed into virtualenvs. The only other tool I can think of that does what poetry is doing right now is pip itself because it always operates on its own virtualenv unless opted out of via --user or sudo.

Unless I'm mistaken I don't see a way for poetry to opt-out of this behavior which may help if you don't want to go back to the old way where it doesn't ever use its venv.

[bertjwregeer]

Installing poetry into a venv where you are also installing your application + dependencies seems to be fraught with issues, especially if you happen to have the same dependencies as poetry and the versions conflict.

For issue #392 what's stopping the user from creating a separate venv just for Poetry and then creating another venv for the application to be installed into and using VIRTUAL_ENV to tell poetry about it?

[bertjwregeer]

Another solution, and one that I don't really think is a good idea, is to add a flag that defaults to False but can be set to True on an individual basis which says to ignore venv detection for the venv Poetry is installed into so that those that manage our tools installation a certain way can do so.

Do note that this is an issue that likely affects pipsi users as well.

[sdispater]

Commit 30965bb should revert the changes and it should not reintroduce the #392 issue.

[bertjwregeer]

Can confirm, this fixes the issue for me! :-)

[sdispater]

Release 0.12.4 is out with this fix included.

[mmerickel]

thanks @sdispater !

[roee-allegro]

I am experiencing this issue with 0.12.17. The way to reproduce is slightly different than @mmerickel 's:

python3 -m venv penv
. penv/bin/activate
pip install poetry
poetry install
# pip freeze output contains the project's requirements