poetry: Poetry using the wrong Python version (not related to pyenv)

Using Poetry 1.0 (prerelease) seems to fix this issue:

poetry self:update --preview
poetry env use python3.7

See https://github.com/sdispater/poetry/pull/731 for more information.

I reinstalled with Python 3 using curl ... | python3 and it still only picks up 2.7.

@zmitchell In 0.12.x, poetry is not bound to the interpreter version you curl the installer script through during installation – so it doesn’t matter which one you install it with with.

If python points to python2 and your project needs python3, you have 2 choices:

1. (preferable) Use pyenv and run pyenv local 3.7.0 or whatever your project wants in the root folder of your project. If you have your pyenv shims setup correctly in your shell startup files, python will now execute Python 3.7.0 whenever python runs from that folder or its subfolders, regardless of what python points to globally.

2. Manually create a virtualenv with Python 3 and activate it prior to running poetry commands. You can use direnv or similar to make that a little more automated, but I still prefer using pyenv – once you get used to it, it’s great

@Peque Well the new poetry env command provides an explicit way to fix the issue (which is great). But the implicit way is still broken. Poetry should implicitly create a built-in virtual environment with the Python version specified by the tool.poetry.dependencies.python property of the pyproject.toml file, not the Python version resolved by the #!/usr/bin/env python shebang line of the ~/.poetry/bin/poetry script.

I’d like to echo @maggyero’s comment: https://github.com/python-poetry/poetry/issues/655#issuecomment-532608560

As a first time new user, installing poetry using the recommended curl method, it was very strange to me that by default poetry install created a Python 2.7 virtual environment for a project marked as Python 3 in pyproject.toml. Especially since Python 2 is end-of-life, there is extra importance in my mind to keep this from happening on new users.

@dreamflasher poetry env use already takes an executable, so this might work for you:

poetry env use $(pyenv which python3.10)

I think it would be nice to be able to specify poetry config python-version 3.7 so that poetry generally defaults to that version of python.

For example poetry new should default to using that version when creating a new project. Currently I have to remember to update the python version from 2.7 to 3.7. In the cases where I forget that leads to some confusion when I call poetry add but can’t access that package in my python interpreter.

Currently when I call poetry new, if I then call poetry env use python3.7 I get:

[NoCompatiblePythonVersionFound]
The specified Python version (3.7.7) is not supported by the project (^2.7).
Please choose a compatible version or loosen the python constraint specified in the pyproject.toml file.`

If I edit the pyproject.toml file to python = "^3.7" instead of 2.7, when I call poetry add I see the following warning message:

The currently activated Python version 2.7.16 is not supported by the project (^3.7).
Trying to find and use a compatible version.
Using python3 (3.7.7)

Which is slightly confusing since no version of python has been “activated” at this point, and I have aliased python to python3, so it is only the poetry env use configuration which is incorrect.

I’ve also been running into issues trying to get poetry installing to the correct version of python when not using a virtual environment (poetry config settings.virtualenvs.create false).

After doing some digging it looks like SystemEnv is still determining the binary to call by appending sys.base_prefix/bin to the executable name given. This approach will not work on linux systems that have versions of both python2 and python3 installed. It seems that a system python environment should be using the system python and simply calling the binary without a specific path. At the moment there seems to be no way to get poetry to install to a linux system python3 installation without changing the /usr/bin/python symlink prior to running poetry install. This is far from ideal. At least if just python was used a shim could be inserted on the path which would allow poetry to install to the correct python version without risking issues with system libraries that call /usr/bin/python.

Ideally it would be nice to just use the version of python poetry was executed with when installing to the system environment.

I solve this problem on my Mac by replacing following line

#!/usr/bin/env python

to

#!/usr/bin/env python3.8

in /home/<name>/.poetry/bin/poetry file. Then it picks python3.8 automatically and there are no annoying warnings anymore.

Ah, here we go. It turns out python was aliased to python3, and doing which python uncovered that. Now python --version returns 2.7.13, and which python returns /usr/bin/python. So how do I get poetry to use Python 3 instead?

Using curl -sSL ... to install is still broken on macOS catalina with homebrewed python3. However, using pip3 install poetry works for me.

Still an issue.

python --version
Python 3.9.16

(saleor-py3.9) x@x-MacBook-Pro-2 saleor % poetry install

Current Python version (3.10.9) is not allowed by the project (~3.9).

If I edit the pyproject.toml file to python = "^3.7" instead of 2.7, when I call poetry add I see the following warning message:

The currently activated Python version 2.7.16 is not supported by the project (^3.7).
Trying to find and use a compatible version.
Using python3 (3.7.7)

Which is slightly confusing since no version of python has been “activated” at this point, and I have aliased python to python3, so it is only the poetry env use configuration which is incorrect.

@JulianFerry If you have already ran poetry install, then a poetry.lock file have been created and is the reason for this issue. I do not know of any argument for poetry add to ignore poetry.lock, so you may need to delete poetry.lock after editing pyproject.toml.

Poetry should implicitly create a built-in virtual environment with the Python version specified by the tool.poetry.dependencies.python property of the pyproject.toml file, not the Python version resolved by the #!/usr/bin/env python shebang line of the ~/.poetry/bin/poetry script.

To give a temporary solution to @maggyero and @johnthagen, yes I agree this is really annoying. For me the best solution on Mac OS has been to manually edit the shebang line of ~/.poetry/bin/poetry to #!/usr/bin/env python3 and I have python3 as a symlink to my python3.8 version from homebrew. Now poetry uses my homebrew version of python to run and, equally important, now sets the python dependency of any new project as python = "^3.8".

❯ poetry new test-demo
Created package test_demo in test-demo
❯ cd test-demo
❯ poetry env info

Virtualenv
Python:         3.8.5
Implementation: CPython
Path:           NA

System
Platform: darwin
OS:       posix
Python:   /usr/local/Cellar/python@3.8/3.8.5/Frameworks/Python.framework/Versions/3.8

This is a relatively elegant, although inconvenient solution to the problem. But you can set it once and forget it, and can modify the shebang line for whatever version of python you want. I think that poetry should have a config option to set the python PATH for the executable it runs and a separate config option for the default dependency version of python set in pyproject.toml for any new project created. Even better would be more argument flags for poetry new to set these things per project at creation time. But this is what we have for now. Hope this helps.

~Upgrading to the latest beta (1.0.0b8) fixed the issue for me:~

The currently activated Python version 3.7.5 is not supported by the project (^3.8).
Trying to find and use a compatible version.
Using python3 (3.8.0)
Creating virtualenv al-research-project in /Users/aljohri/Development/al-research-project/.venv

p.s. hi @tatianafrank!

EDIT: Actually, no it didn’t fix it. Despite the message that says it will use 3.8.0, the virtualenv uses poetry’s python version:

$ /Users/aljohri/Development/al-research-project/.venv/bin/python --version
3.7.5

Here’s some debug information:

As you can see, I’m using asdf (which is basically equivalent to pyenv but allows for multiple languages).

Additionally, I have poetry installed via pipx (a common way to install python CLI tools in their own isolated virtualenvs):

$ pipx install poetry --pip-args=--pre
  installed package poetry 1.0.0b8, Python 3.7.5
  These apps are now globally available
    - poetry
done! ✨ 🌟 ✨
$ which poetry
/Users/aljohri/.local/bin/poetry

@trompx This is described in the FAQ: https://python-poetry.org/docs/faq/#why-is-poetry-telling-me-that-the-current-projects-python-requirement-is-not-compatible-with-one-or-more-packages-python-requirements

Still an issue for me too, fresh pyenv and poetry install on WSL2, installed both using the official script. Pyenv is activated, which python, python --version points to the my correct pyenv install (3.11.2). I’m trying to spawn a poetry shell (after poetry env use 3.11), but it says my activated python is 3.10 (my system python)

Just another copy&paste takeaway for the working solution on unix-systems:

sed -i 's/#\!\/usr\/bin\/env python/#\!\/usr\/bin\/env python3/g' ~/.poetry/bin/poetry

Also not using pyenv. pip3 install poetry worked for me, whereas all the other suggestions did not. On Amazon Linux 2, which still runs 2.7 by default.

None of the above works if youre trying to run poetry from crontab

The only thing that works for me (until i can use the new env feature) is running pyenv shell <version>. Unfortunately pyenv local and pyenv global dont work and my virtual environment is not getting picked up otherwise. Obviously this is not a good solution but a workaround for now…

@zmitchell For now, your best bet is to use pyenv (which is the easiest way to manager different Python versions if you are not on Windows) until #621 is implemented (work in progress here https://github.com/sdispater/poetry/tree/env-command)