Cannot configure options through environment variables

[jpreese]

• [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 Montery version 12.4
• Poetry version: 1.2.0b2

Issue

When calling poetry using environment variables to configure options, they do not seem to be respected. From the documentation, I would expect to be able to create a virtual environment without pip using something like the following:

POETRY_VIRTUALENVS_OPTIONS_NO_PIP=true POETRY_VIRTUALENVS_IN_PROJECT=true POETRY_VIRTUALENVS_PATH=.venv poetry install

The last two values work. Poetry is installed in the project in a folder named .venv -- however, pip is still in the site-packages folder.

I've tried the other "options" as well, and tried different ways to name them but have not been successful.

Are options able to be configured by environment variables?

[dimbleby]

Looks like not - see https://github.com/python-poetry/poetry/blob/8b640886ee39aee4a6c3208f39febf368dc32953/src/poetry/utils/env.py#L983

that'll cause poetry to look for the POETRY_VIRTUALENVS_OPTIONS environment variable - which doesn't help at all

[l-rossetti]

still no way to make --always-copy work for virtualenv creation?

[dimbleby]

this issue is about not being able to configure those options through environment variables, per https://github.com/python-poetry/poetry/issues/7873#issuecomment-1534749384 it works fine when configured another way

[nfantone]

I was hit by this today. POETRY_VIRTUALENVS_OPTIONS_NO_PIP=true seems to have no effect.

This is the end result of my venv after poetry install.

sh-5.2$ ls .virtualenvs/my-venv/bin -la
total 56
drwxr-xr-x 2 user user 4096 Dec 11 10:45 .
drwxr-xr-x 5 user user 4096 Dec 11 10:44 ..
-rw-r--r-- 1 user user 9033 Dec 11 10:44 Activate.ps1
-rw-r--r-- 1 user user 2354 Dec 11 10:44 activate
-rw-r--r-- 1 user user  936 Dec 11 10:44 activate.csh
-rw-r--r-- 1 user user 2215 Dec 11 10:44 activate.fish
-rwxr-xr-x 1 user user  292 Dec 11 10:44 django-admin
-rwxr-xr-x 1 user user  246 Dec 11 10:45 gunicorn
-rwxr-xr-x 1 user user  250 Dec 11 10:44 pip
-rwxr-xr-x 1 user user  250 Dec 11 10:44 pip3
-rwxr-xr-x 1 user user  250 Dec 11 10:44 pip3.12
lrwxrwxrwx 1 user user   21 Dec 11 10:44 python -> /usr/local/bin/python
lrwxrwxrwx 1 user user    6 Dec 11 10:44 python3 -> python
lrwxrwxrwx 1 user user    6 Dec 11 10:44 python3.12 -> python
-rwxr-xr-x 1 user user  245 Dec 11 10:44 sqlformat

sh-5.2$ pip --version
pip 23.2.1 from /home/user/.virtualenvs/my-venv/lib/python3.12/site-packages/pip (python 3.12)

[jyligehc]

Using Poetry version 1.7.1 (on Windows 10) noticed same issue with POETRY_VIRTUALENVS_OPTIONS_SYSTEM_SITE_PACKAGES.

Setting it to true will show correctly in the config list: virtualenvs.options.system-site-packages = true

But when creating the venv (poetry install) or running poetry env use <python> The line in pyvenv.cfg is not set correctly: include-system-site-packages = false

If using command poetry config --local virtualenvs.options.system-site-packages true the project's poetry.toml is updated correctly and also pyvenv.cfg has correct setting in venv.

[alexandreteles]

Using Poetry version 1.7.1 on Ubuntu (WSL2) and I can also reproduce this error. I did notice, however, that some flags work. For example, POETRY_VIRTUALENVS_IN_PROJECT=true resulted in the .venv being created in the project's root.

[dimbleby]

folks, this all has been well understood since https://github.com/python-poetry/poetry/issues/5906#issuecomment-1166260363. No need to keep reporting that it is still a thing - that's represented already by this still being open.

what this issue needs now is someone who cares enough to make a merge request fixing it: if that's you then please go ahead!

[dimbleby]

Fixed at #9015

[github-actions[bot]]

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.