Poetry: [virtualenvs] configuration not working with pyproject.toml

[lcbm]

• [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.
• [ ] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: Linux 5.8.9-arch2-1 x86_64
• Poetry version: 1.0.10
• Link of a Gist with the contents of your pyproject.toml file: :point_down:

[tool.poetry]
name = "name"
version = "0.1.0"
description = "description"
authors = ["my-name [email protected]"]
license = "BSD-3-Clause"

[tool.poetry.dependencies]
python = "^3.8"

[tool.poetry.dev-dependencies]
pre-commit = "^2.7.1"
pylint = "^2.6.0"
pytest = "^6.0.2"
pytest-cov = "^2.10.1"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

[virtualenvs]
create = true
in-project = true

Issue

Hello, I've been trying to make Poetry create the virtual environment folder in the project's root but it kept installing in home/leleco/.cache/pypoetry/virtualenvs despite the configuration set in pyproject.toml file.

After a few tries, I ran poetry config --list and the output was this :point_down:

cache-dir = "/home/leleco/.cache/pypoetry"
virtualenvs.create = true
virtualenvs.in-project = false
virtualenvs.path = "{cache-dir}/virtualenvs"  # /home/leleco/.cache/pypoetry/virtualenvs

This got me startled, so I tried poetry config virtualenvs.in-project true, then poetry install and it worked: a .venv was created inside my project's root directory. I then tried the same, except that with virtualenvs.create :point_down:

# pyproject.toml

[virtualenvs]
create = false
in-project = true

And the result from poetry config --list was this :point_down:

cache-dir = "/home/leleco/.cache/pypoetry"
virtualenvs.create = true
virtualenvs.in-project = true
virtualenvs.path = "{cache-dir}/virtualenvs"  # /home/leleco/.cache/pypoetry/virtualenvs

With this, I concluded that [virtualenvs] does not work with pyproject.toml (which was expected to me, as a user). Furthermore, poetry config virtualenvs.in-project true --local creates a poetry.toml instead of adding an entry in pyproject.toml. :point_down:

# poetry.toml

[virtualenvs]
in-project = true

Is this expected? If so, I couldn't find the documentation explaining this... also, is there a chance that we convert this issue from Bug to Feature Request in case the described behavior is the expected behavior? I'm more than glad to update this description and convert it to a feature request with proper use-case description.

Thanks in advance,
Hope I can be useful to resolve this, or to implement this feature, somehow :partying_face:

[itsthejoker]

To the best of my knowledge, using a key called [virtualenvs] has never been supported, nor has overriding config options in the pyproject.toml -- the poetry settings are used to handle processing for the pyproject.toml, so it makes sense that they are separate.

[lcbm]

I see your point and partially agree with the argument. Nevertheless, I believe there's at least one action item for this issue: better document poetry.toml. I read through the docs for a while and found nothing on this issue (pyproject.toml vs poetry.toml). Not even on stackoverflow I found much about it (the most I got was someone mentioning poetry.toml existed, but it was such an old post that I simply thought it was a deprecated Poetry configuration file).

For me, this is really a pain because VS Code doesn't work with the default poetry venv dir (there are issues open on this) and VS Code users HAVE to change venv's directory in order to use poetry venv. In order to avoid that my team has problems with poetry and VS Code, I looked for a way to enforce poetry to install venv in the project's root everytime (that way, VS Code would always find the venv folder). This being said, I can see that lots of developers will spend considerable time looking for an appropriate solution for their professional projects and not finding proper documentation and relying on trial and error or workarounds. I believe this justifies adding some documentation on poetry.toml and it's usage, what configs could go there and so on.

Lastly, an opinion on the separation of files: we have black, isort and many other tool configurations under pyproject.toml -> [tools.<tool-name>]. I don't see why we can't have a project setting (where to install venv, for this specific project) in the same file (pyproject.toml) under different keys in order to avoid increasing the number of files. :thinking:

See this example of a all-in-one configuration file (there are many other examples).

Just to be clear, I really appreciate your help and opinion... this is a IMO response only, based on bad UX regarding the documentation (not Poetry itself, which is so awesome that I'm trying to change my peers mind to use it in our project) :smile:

[finswimmer]

Hello @lcbm,

the reason why the local configs are not in pyproject.toml but in a separate poetry.toml is that one developer should not force another how poetry is configured. This would automatically the case if these local config would be in the pyproject.toml.

But it's a good idea to document the existens of this file and would fit at best in the Local Configuration section of the docs.

PR is welcome :)

fin swimmer

[max-sixty]

the reason why the local configs are not in pyproject.toml but in a separate poetry.toml is that one developer should not force another how poetry is configured. This would automatically the case if these local config would be in the pyproject.toml.

Could I ask what the difference between having the _local_ config in poetry.toml and pyproject.toml is, on this dimension?

[finswimmer]

Could I ask what the difference between having the local config in poetry.toml and pyproject.toml is, on this dimension?

The pyproject.toml contains information about your package, like metadata and dependencies. Anything that is needed to build the package.

The poetry.toml contains the local configuration of the poetry application. One should not check-in this file into a repository, because these configuration are just personal flavors.

[max-sixty]

One should not check-in this file into a repository, because these configuration are just personal flavors.

I see, thanks @finswimmer