Poetry doesn't use custom pyenv environment
Description
I prefer to keep my venvs controlled by pyenv and located in the project directory. This is how I create a new virtual environment ("poetry-playground" is the name of the current directory):
poetry-playground PYENV_VERSION=3.12.2 python -m venv venv
poetry-playground source venv/bin/activate
At this point, venv (located in "venv" folder) is created and activated. Next, I init a new poetry project inside venv:
(venv) ➜ poetry-playground poetry init
This command will guide you through creating your pyproject.toml config.
Package name [poetry-playground]:
Version [0.1.0]:
Description []:
Author [None, n to skip]: n
License []:
Compatible Python versions [^3.12]:
Would you like to define your main dependencies interactively? (yes/no) [yes] no
Would you like to define your development dependencies interactively? (yes/no) [yes] no
Next, I want to add requests, but somehow it installs not to the current venv, but somewhere else (presumably, to system interpreter):
(venv) ➜ poetry-playground poetry add requests
Skipping virtualenv creation, as specified in config file.
Using version ^2.32.3 for requests
Updating dependencies
Resolving dependencies... (0.1s)
No dependencies to install or update
Writing lock file
And of course, no requests is installed to the current venv.
The question is: is it possible to use poetry in this kind of environment? I've been using pip for years and trying to switch to poetry right now, so maybe I'm missing something. As you can see in "poetry configuration" section below, I already have:
virtualenvs.prefer-active-python = true
virtualenvs.create = false
virtualenvs.in-project = true
If I set virtualenvs.create to true, then my venv is ignored and poetry creates a new venv in ./.venv directory. This is not something I want. Again, I want to create my own venv using pyenv (with any Python version I like) and then control it with poetry.
Thanks in advance!
Workarounds
None that I'm satisfied with
Poetry Installation Method
other
Operating System
MacOS 14.5 Sonoma
Poetry Version
Poetry (version 1.8.3)
Poetry Configuration
cache-dir = "/Users/groosha/Library/Caches/pypoetry"
experimental.system-git-client = false
installer.max-workers = null
installer.modern-installation = true
installer.no-binary = null
installer.parallel = true
keyring.enabled = true
solver.lazy-wheel = true
virtualenvs.create = false
virtualenvs.in-project = true
virtualenvs.options.always-copy = false
virtualenvs.options.no-pip = false
virtualenvs.options.no-setuptools = false
virtualenvs.options.system-site-packages = false
virtualenvs.path = "{cache-dir}/virtualenvs" # /Users/groosha/Library/Caches/pypoetry/virtualenvs
virtualenvs.prefer-active-python = true
virtualenvs.prompt = "{project_name}-py{python_version}"
warnings.export = true
Python Sysconfig
No response
Example pyproject.toml
No response
Poetry Runtime Logs
(venv) ➜ poetry-playground poetry add requests
Skipping virtualenv creation, as specified in config file.
Using version ^2.32.3 for requests
Updating dependencies
Resolving dependencies... (0.1s)
No dependencies to install or update
Writing lock file
I would also like to add this strange output, while already having venv (installed with pyenv) activated:
(venv) ➜ poetry-playground poetry env info
Virtualenv
Python: 3.11.7
Implementation: CPython
Path: NA
Executable: NA
Base
Platform: darwin
OS: posix
Python: 3.11.7
Path: /Library/Frameworks/Python.framework/Versions/3.11
Executable: /Library/Frameworks/Python.framework/Versions/3.11/bin/python3.11
This is absolutely wrong, because despite having 3.11 as system interpreter, virtual environment uses 3.12.2
@MasterGroosha: See if this workaround is relevant to you: https://github.com/python-poetry/poetry/issues/8119#issuecomment-2157934433
Hey @MasterGroosha,
the workflow you describe should work. So I guess there must be some problem on your system.
You haven't come back for quite a while, so I assume you've solved it somehow and I can close this issue.
If you disagree feel free to leave a comment.
fin swimmer
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.