Option to create virtual environments in the project root (.venv)

I’m considering migrating some of my projects from pipenv to poetry. I would like to be able to tell poetry to create virtual environments at ./.venv/ to support Makefile target dependencies, CI build caching, and automatic IDE support.

I added a feature to pipenv to detect and use virtual environments located at ./.venv/ based on the mere presence of a directory of that name. It looks like poetry nearly has the same behavior:

https://github.com/sdispater/poetry/blob/87c4aaf9cadbbb6c5657101d715b5a4e1a8d9a05/poetry/utils/venv.py#L55-L59

but I noticed that if .venv is an empty directory (in order to let the tool populate it) poetry seems to install dependencies into my global Python instead.

Would you consider a PR to add another case to this logic to create virtual environments in the root of a project? This should allow poetry to handle all of the following scenarios:

• Use the currently activated virtual environment ($VIRTUAL_ENV set)
• Use the exiting local virtual environment (./.venv/<bin>/python exists)
• [NEW] Create a new local virtual environment (./.venv/ is empty)
• Use the previously cached virtual environment
• Create a new cached virtual environment

[sdispater]

The new settings.virtualenvs.in-project setting is now available. You can activate it with:

poetry config settings.virtualenvs.in-project true

[joshfriend]

I’ve been reading and commenting on threads like this both in Poetry and Pipenv for well over 2 years now and it seems pretty clear to me that the most beneficial default is having in-project be true. I think a LOT of people don’t care either way, probably because they don’t understand the benefits of in-project, whose docs mention zero reasons for or against using it. Then there are the users like myself who actually do care, because we want our development tools to integrate easily with each other.

The remaining users have a few (valid) edge cases that they care about which I’m fairly certain make up the minority:

1. Reducing backup size and clutter
2. Another case I saw on a different thread was about using poetry/pipenv locally and with a docker container simultaneously. in-project would cause the venv to be shared with two incompatible platforms, whereas the hidden venv option takes care of that

I don’t think either is difficult to work around, and I think the benefits of compatibility with PyCharm/VSCode/etc should carry more weight in the decision of what should be the default.

Further, to what @b-long is saying above me, I knew exactly what I wanted poetry to do for me and I still found it difficult to find the CLI command to set that flag or write it manually in pyproject.toml.

in-project=true as the default would be amazing for the development experience. I’m 🙏 begging y’all to change it 😆