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

Alternatively, an option in pyproject.toml to specify the virtual environment location would also be great!

I might add a setting that can be set via the config command to tell poetry to create the virtualenv inside the project directory.

The only downside to that is that you can only have one virtualenv by project.

@jacebrowning

@jacebrowning isn't there a config option already? https://github.com/sdispater/poetry/blob/87c4aaf9cadbbb6c5657101d715b5a4e1a8d9a05/poetry/utils/venv.py#L64
Not a command-line one, though, yet.

@buriy

@buriy How might I use that? I'm having trouble understanding the documentation here:

$ poetry config -h
Usage:
  config [options] [--] <key> [<value>]...

...

 To add a repository:

     poetry repositories.foo https://bar.com/simple/

 To remove a repository (repo is a short alias for repositories):

     poetry --unset repo.foo

$  poetry virtualenvs.path .venv

[CommandNotFound]
Command "virtualenvs.path" is not defined.

$ poetry config virtualenvs.path .venv

[ValueError]
Setting virtualenvs.path does not exist

config [--list] [--unset] [--] <key> [<value>]...

$ poetry config settings.virtualenvs.path .venv

[ValueError]
Setting settings.virtualenvs.path does not exist

config [--list] [--unset] [--] <key> [<value>]...

@jacebrowning

@jacebrowning I guess if you manually create the config.toml file, it would work, but there's no CLI support for that right now. Please, could you try if that works?

@buriy

@buriy @jacebrowning This setting is here to tell poetry where to create every virtualenv so it wouldn't work for this use case. That's why I am thinking of adding a new setting to tell poetry to create the virtualenv for the current project inside the .venv directory.

Having a .venv directory would be great since many tools look there for formatting tools and the like, specifically I am thinking of ALE for Vim.

Just wanted to point out the similarity to the approach Rust's package manager cargo has. cargo creates a directory target in the project root where it places all the dependencies and compilation artifacts. The proposed .venv directory seems to go in the same direction.

@kelseasy

@kelseasy I just thought it would be fun to share this: https://pythonclock.org/

Usually tox is used if you need to test several versions, and I haven't seen anybody who needs to have several venvs for a reason other than that. Only for upgrade maybe but then you can set up 2 project folders, each with its venv. Support for several venvs is ok, but if having only one venv simplifies things greatly, and doesn't hurt anyone, why not introducing this limit? ср, 23 мая 2018, 5:07 Kelsey Z <notifications@github.com>:

…

python packages can/have to support both python2 and python3, whereas you rarely need multiple rust versions to compile with. Something along these lines in the pyproject.toml being used to create venvs could go a long way: [tool.poetry.virtualenvs].venv = { python = "~2.7" }.venv3 = { python = "^3.5" } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#108 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABShBuar33_GQtedJC73OtlNG3yLAyfks5t1IwPgaJpZM4UAPUe> .

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

poetry config settings.virtualenvs.in-project true

And VSCode

Local .venvs are also automatically recognized by PyCharm.

There is also the problem that shared configuration in VSCode does not really work without local envs.
The shared configuration takes a path - and this path is different for every user if the .venv is not in the project directory.
Honestly, bkacups are not even on my radar, I use git and a matching .gitignore.

Why not using a $ variable ?

I'm surprised that the poetry.toml file hasn't been mentioned on this thread. I place a file called poetry.toml into all of my Python projects:

[virtualenvs]
create = true
in-project = true

This produces a local .venv/ folder, and you can configure your editor to point to it using a relative path. For example, with VSCode, you could place this in settings.json:

"python.pythonPath": "${workspaceFolder}/.venv/bin/python"

@b-long

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:

Reducing backup size and clutter
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 😆

I'm surprised that the poetry.toml file hasn't been mentioned on this thread. I place a file called poetry.toml into all of my Python projects:
[virtualenvs]
create = true
in-project = true
This produces a local .venv/ folder, and you can configure your editor to point to it using a relative path. For example, with VSCode, you could place this in settings.json:
"python.pythonPath": "${workspaceFolder}/.venv/bin/python"

But does that the path configuration works too? Because it seems to be ignored.
Source: https://python-poetry.org/docs/configuration/#virtualenvspath-string

The setting has now changed to:

poetry config virtualenvs.in-project true

poetry config virtualenvs.in-project true --local

could be useful for enabling it exclusively in a project. For example you may want to use a formatter installed with dev dependency in settings.json in vscode as in settings.json:

{
  "python.formatting.provider": "black",
  "python.formatting.blackPath": "${workspaceFolder}/.venv/bin/black"
}

Fix for including modules from different locations (python-poetry#108)

@Cito

@Cito, you mean poetry config --local virtualenvs.in-project true?

This is the thing everyone needs.

is it possible to set this configuration in pyproject.toml. I tried the below but it wont work

[virtualenvs]
in-project = true

It is set in poetry.toml which is the local configuration file for Poetry instances. This is both covered in the documentation and the above suggested command (poetry config --local virtualenvs.in-project true).

I Have set this in poetry.toml. I don't love having another toml, so I tried to add to pyproject.toml under tool.poetry.virtualenvs but it did not work, and even triggered a lot of vscode warnings.

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.

Navigation Menu

Repository navigation

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

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

jacebrowning commented on May 16, 2018

sdispater commented on May 17, 2018

buriy commented on May 18, 2018

jacebrowning commented on May 18, 2018

buriy commented on May 19, 2018

sdispater commented on May 19, 2018

digitalresistor commented on May 19, 2018

Victor-Savu commented on May 21, 2018

Victor-Savu commented on May 26, 2018

buriy commented on May 26, 2018

sdispater commented on May 28, 2018

19 remaining items

mikelnrd commented on Feb 19, 2020

ChristianSauer commented on May 14, 2020

gsemet commented on May 14, 2020

b-long commented on May 14, 2020

joshfriend commented on May 14, 2020

mfoglio commented on May 27, 2020

Pet3ris commented on Jul 23, 2021

n-ae commented on Jan 4, 2022

hector97i commented on Jun 12, 2022

lordvcs commented on Oct 31, 2022

neersighted commented on Oct 31, 2022

Lewiscowles1986 commented on Aug 4, 2023

github-actions commented on Feb 29, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions