Poetry 0.12.3 uses Python 2.7.10 despite specifying 3.7.0

[maxcountryman]

• I am on the latest Poetry version.
• 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: macOS Mojave
• Poetry version: 0.12.3
• Link of a Gist with the contents of your pyproject.toml file:

Issue

No matter what I do, Poetry uses Python 2.7.10.

For instance, I've downloaded and specified Python 3.7.0 with pyenv:

$ pyenv install 3.7.0
$ pyenv local 3.7.0

My pyproject.toml specifies:

[tool.poetry.dependencies]
python = "3.7.0"
...

Yet poetry update yields:

[SolverProblemError]
The current supported Python versions are 2.7.10
Because hug (2.4.1) requires Python >=3.4
 and no versions of hug match >2.4.1,<3.0.0, hug is forbidden.
So, because <...> depends on prodigy (1.6.1) which depends on hug (>=2.4.1,<3.0.0), version solving failed.

I'm completely mystified.

Infuriatingly, if I instead specify python = "3.2" Poetry will gladly use Python 3.2...

[sdispater]

Could you provide a complete pyproject.toml that reproduces this issue?

[maxcountryman]

This seems to do it:

[tool.poetry]
name = "test"
version = "0.1.0"
description = ""
authors = ["Max Countryman <maxc@me.com>"]

[tool.poetry.dependencies]
python = "3.7.0"
hug = "2.4.1"

[tool.poetry.dev-dependencies]
pytest = "^3.0"

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

As seen previously:

[SolverProblemError]
The current supported Python versions are 2.7.10
Because test depends on hug (2.4.1) which requires Python >=3.4, version solving failed.

[sobolevn]

The same happens for me.

I have installed poetry using curl from the official site.
Also have this line in the pyproject.toml: python = "^3.6 || ^3.7"

Execution:

» poetry lock          
Creating virtualenv wemake-django-rest-py2.7 in /Users/sobolev/Documents/github/wemake-django-rest/.venv
Updating dependencies
Resolving dependencies... (0.4s)

[scullionw]

Same issue. Using macOs mojave as well.

I have python 3.7 installed and it uses py2.7, no matter what I set in the pyproject.toml.

Note that on a mac, even after install python 3 with homebrew,

$ python still points to 2.7

and only

$ python3

points to the python 3.7 installed by homebrew.

Williams-MacBook-Pro:Local Projects williamscullion$ poetry new poetry-demo
Created package poetry-demo in poetry-demo
Williams-MacBook-Pro:Local Projects williamscullion$ cd poetry-demo/
Williams-MacBook-Pro:poetry-demo williamscullion$ subl .
Williams-MacBook-Pro:poetry-demo williamscullion$ cat pyproject.toml
[tool.poetry]
name = "poetry-demo"
version = "0.1.0"
description = ""
authors = ["scullionw <scuw1801@usherbrooke.ca>"]

[tool.poetry.dependencies]
python = "3.7"

[tool.poetry.dev-dependencies]
pytest = "^3.0"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"
Williams-MacBook-Pro:poetry-demo williamscullion$ which python3
/usr/local/bin/python3
Williams-MacBook-Pro:poetry-demo williamscullion$ python3 --version
Python 3.7.0
Williams-MacBook-Pro:poetry-demo williamscullion$ poetry add requests
Creating virtualenv poetry-demo-py2.7 in /Users/williamscullion/Library/Caches/pypoetry/virtualenvs

As you can see, 2.7 was used. (poetry-demo-py2.7)

And

Williams-MacBook-Pro:poetry-demo williamscullion$ poetry run python -V
Python 2.7.15

[sdispater]

You should switch to a Python version that is supported by what you specified in your pyproject.toml. Poetry will not use the appropriate Python version automatically.

For more information about this see my comment #439 (comment). Also the documentation explains it https://poetry.eustace.io/docs/basic-usage/#poetry-and-virtualenvs

Note that in a near future if you have a mismatched Python version it will raise an error to avoid this confusion.

As it is, this is not really a bug only a poor user experience.

I think the next bugfix release will only display a warning for now and the next major version will raise an error.

[maxcountryman]

But I did specify the Python version in my pyproject.toml (i.e. “3.7.0”) yet Poetry still doesn’t use it.

[sdispater]

@maxcountryman That's what I said. Your pyproject.toml specifies 3.7.0 but your currently activated Python version is 2.7. And Poetry will not try to find your Python 3.7 exectuable to create the virtualenv but will use Python 2.7, hence the error.

[maxcountryman]

How do you mean? I’ve used pyenv, as I previously stated, to set my Python version. Why isn’t Poetry respecting that? To me, that seems like a bug.

[sdispater]

@maxcountryman Can you execute update with -vvv to have the complete traceback and output?

[sdispater]

And also: how did you installed Poetry?

[maxcountryman]

I’ll have to take a look on Monday when I’m back at work. I installed via curl.

[maxcountryman]

Truncated result of poetry update -vvv:

[SolverProblemError]
The current supported Python versions are 2.7.10
Because test depends on hug (2.4.1) which requires Python >=3.4, version solving failed.
Exception trace:
 /Users/max/.poetry/lib/poetry/_vendor/py2.7/cleo/application.py in run() at line 94
   status_code = self.do_run(input_, output_)
 /Users/max/.poetry/lib/poetry/console/application.py in do_run() at line 88
   return super(Application, self).do_run(i, o)
 /Users/max/.poetry/lib/poetry/_vendor/py2.7/cleo/application.py in do_run() at line 197
   status_code = command.run(input_, output_)
 /Users/max/.poetry/lib/poetry/console/commands/command.py in run() at line 77
   return super(BaseCommand, self).run(i, o)
 /Users/max/.poetry/lib/poetry/_vendor/py2.7/cleo/commands/base_command.py in run() at line 146
   status_code = self.execute(input_, output_)
 /Users/max/.poetry/lib/poetry/_vendor/py2.7/cleo/commands/command.py in execute() at line 107
   return self.handle()
 /Users/max/.poetry/lib/poetry/console/commands/update.py in handle() at line 41
   return installer.run()
 /Users/max/.poetry/lib/poetry/installation/installer.py in run() at line 76
   self._do_install(local_repo)
 /Users/max/.poetry/lib/poetry/installation/installer.py in _do_install() at line 216
   ops = solver.solve(use_latest=whitelist)
 /Users/max/.poetry/lib/poetry/puzzle/solver.py in solve() at line 37
   packages, depths = self._solve(use_latest=use_latest)
 /Users/max/.poetry/lib/poetry/puzzle/solver.py in _solve() at line 154
   raise SolverProblemError(e)
update [--no-dev] [--dry-run] [--lock] [--] [<packages>]...

After running pyenv local 3.7.0 and with this pyproject.toml:

[tool.poetry]
name = "test"
version = "0.1.0"
description = ""
authors = ["Max Countryman <maxc@me.com>"]

[tool.poetry.dependencies]
python = "3.7.0"
hug = "2.4.1"

[tool.poetry.dev-dependencies]
pytest = "^3.0"

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

[sdispater]

That's what I suspected. You have an issue in your system since even though you execute pyenv local 3.7.0, Poetry picks up Python 2.7 as the currently activated Python.

After doing pyenv local 3.7.0, what's the output of python -V?

[drivasperez]

Hi, just chiming in to say that I also had this issue, also on macOS 10.14 Mojave. In my case, Poetry was refusing to recognise that I was using Python 3, and as such refusing to install Django 2.1. It was resolved by using pyenv local 3.7.0 to generate a .python-version file in my project directory.

This was confusing—I came here to file an issue, before finding this one and investigating further—because I had used pyenv global 3.7.0 to set my Python version to 3.7.0. So python -V gave me Python 3.7.0, but Poetry wouldn't recognise this. I don't know if this is a bug (maybe on Mac OS X?), under-explained or just a detail I missed while going through the docs. In all likelihood, it was the latter.

Also, because people might come across this issue when the actual problem is that they haven't set Pyenv up properly, if after setting python local 3.7.0 your Python version is still stuck at 2.7, make sure to add the proper commands to the end of your .bashrc or .zshrc files, as specified on the project page:

Define environment variable PYENV_ROOT to point to the path where pyenv repo is cloned and add $PYENV_ROOT/bin to your $PATH for access to the pyenv command-line utility.

$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile

Zsh note: Modify your ~/.zshenv file instead of ~/.bash_profile. Ubuntu and Fedora note: Modify your ~/.bashrc file instead of ~/.bash_profile. Proxy note: If you use a proxy, export http_proxy and HTTPS_PROXY too.

Add pyenv init to your shell to enable shims and autocompletion. Please make sure eval "$(pyenv init -)" is placed toward the end of the shell configuration file since it manipulates PATH during the initialization.

$ echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n eval "$(pyenv init -)"\nfi' >> ~/.bash_profile

Zsh note: Modify your ~/.zshenv file instead of ~/.bash_profile. Ubuntu and Fedora note: Modify your ~/.bashrc file instead of ~/.bash_profile.

I hope that helps someone, and apologies for the long post.

[sdispater]

because I had used pyenv global 3.7.0 to set my Python version to 3.7.0. So python -V gave me Python 3.7.0, but Poetry wouldn't recognise this.

That's odd.

I have the exact same setup and I don't need to use pyenv local for Poetry to pick up my globally set Python version (which is 3.7.0 as of this writing).

I am not sure what's happening here.

[drivasperez]

I'll try to replicate the problem on my machine in the morning. I did a lot of futzing around to get things to work and I don't want to send you off on a wild goose chase just because I forgot I did something.

[drivasperez]

I reinstalled Poetry and Pyenv, and did not get a repeat of the global issue. So I don't know what happened, but I'd guess I misconfigured Pyenv in some way.

[maxcountryman]

I tried reinstalling everything, but no dice. I even tried this on a separate laptop and ran into the same issues.

[sdispater]

@maxcountryman Did you see my comment #536 (comment)?

What's the output of python -V? 

[maxcountryman]

Ah it seems to still be pointing to 2.7.x--not sure why that would be since it's a fresh install of pyenv and I've followed the rest of their setup to the T.

[maxcountryman]

I'll raise an issue with pyenv since it seems something isn't right there. Thanks!

[bdoms]

I realize this is a closed issue and I'm not suggesting repoening it, as there isn't a bug (the program works as designed). However, the behavior is still not ideal, and I found this page because I was running into the same issues still today months later. Not being able to specify a Python version is a huge pain on some systems. In some cases you can't just switch what the active version is.

So I suggest that being able to specify a Python version be a new feature if it isn't on the roadmap. That behavior already exists with virtualenv with the -p option, so simply creating something in poetry that could forward along an argument to that would go a long way.

Since I found this while doing random web searches for the problem I also wanted to point out a quick hack I used that effectively solved this problem for me in the hopes that it helps out others. Simply add an alias to your .bashrc or similar, like this:

alias poetry="python3 $HOME/.poetry/bin/poetry"

Voila, the poetry command now uses the version of Python you want.

[sjuxax]

For what it's worth, this should be considered a bug.

The official recommendation is to leave the primary python binary pointing to Python2 indefinitely to allow smooth co-existence of version-naive scripts, see PEP 394. Python 3.x is only supposed to be accessible by python3. If Python 2 is not installed, there should not be a /usr/bin/python.

Some distributions have chosen to break this packaging recommendation and in general it works OK as long as you're using software from their repos, where they've replaced all the shebangs accordingly, but on many systems, including macOS, it can and will break things to link /usr/bin/python to the 3.x interpreter.

While there's been some discussion around whether the recommendation should be maintained long-term, given that the official recommendation is for /usr/bin/python to always point to the system's Python 2.x interpreter, Poetry should not assume that /usr/bin/python always represents the "activated interpreter".

[serkef]

I also had the same issue. I have an alias for python=python3.6, so it was much harder to debug this (because python -V gives 3.6). I would love a choice on installation step to pick one of my existing python versions.

[sjuxax]

Took a quick look at the code on this -- there are several places that directly invoke python. It seems like the environment bootstrap should provide a way to test for various installed Python paths and fall back to python only if a more specific Python executable is not available. Even distros that install python3 as python usually provide python3 and python2 bins, along with even-more-specific python2.7 and python3.7. From a glance, I'm not really sure where the best place to set this up would be. Tried a couple of very quick and dirty hacks that sorta worked but didn't have the time to figure out what makes sense.

@sdispater, any general guidance here? It would also be useful if there was a high-level overview of the code's architecture somewhere.

[finswimmer]

@trickeydan : Please scroll some post up and read @sdispater explanation about it.

I would even go one step further: From January 2020 on python2 is dead. Why should poetry should take care about it anymore?

[dmontagu]

@trickeydan

But it does work on most distros; it just requires you to have an appropriately configured combination of python, poetry, and environment. This will always be a requirement.

To me, it feels more like a configuration issue / user experience issue than a bug; sdispater (and several others) called it out as such above (as noted by @finswimmer above as well).

The main justification in this thread that I see for considering it a "bug" is the reference to PEP 394, but this has been updated and no longer makes the recommendation that was initially referenced, as noted by @maggyero. In particular, PEP 394 explicitly states that python distributors may set the behavior of the python command to python3. Given this, it feels like it may even be better to keep it referencing the python command anyway so that it doesn't needlessly break usage with 2.7.

Ultimately, it seems like a choice of what you want to break, not whether you want to break something. And again, given that workarounds abound for any combination of system-environment requirements, this doesn't really feel like a bug to me so much as a user experience issue.

---

Given the breadth of (unrelated) topics discussed above (e.g., issues with pyenv), if you really want to push for a change in behavior and don't want to start by making a PR, it probably would make more sense to create a new issue with a specific focus on a proposal for how you'd change things if you were to create a PR.

[maxcountryman]

...this doesn't really feel like a bug to me so much as a user experience issue

Considering this is a tool which produces as a primary artifact a user experience over lower-level aspects of Python packaging, it boggles my mind that a user experience issue not be considered a bug.

So it goes I suppose.

[dmontagu]

@maxcountryman I agree that user experience should be a priority for a tool like poetry, but just because an issue is high priority, it doesn't make it a "bug" per se.

With regard to this issue, (as noted above) poetry is behaving as intended, works properly without modification in many environments, and requires only minor modifications to system environment in others. Moreover, there is explicit justification for the current design.

Contrast this with issues where poetry is behaving in an unintended way without simple workarounds, which (in my opinion) do deserve the label "bug". A few examples:

• pip 19.2. breaks poetry (private repository) #1249 (can't use poetry with private pypi if password has special characters)
• Searching for pygame results in ValueError #1345 (searching for packages with incorrect metadata crashes poetry)
• Poetry version command format first without bumping #1442 (calling poetry version when the pyproject.toml is out of order only reorders the file, rather than updating the version)

These issues may or may not deserve to be considered higher priority than a user experience issue, but are much more clearly bugs.

I recognize this is just semantics, but given the core development team's stated goal of prioritizing "bug fixes" (especially prior to a non-beta 1.0 release), I think it's worth the distinction.

---

Apologies for derailing this issue to some degree; given this issue is closed though I think further discussion of this problem probably merits the creation of a new issue.

[trickeydan]

@trickeydan : Please scroll some post up and read @sdispater explanation about it.

I've been following this issue for several months. I know what the project maintainers think.

I would even go one step further: From January 2020 on python2 is dead. Why should poetry should take care about it anymore?

It's deprecated. Not dead. It will live on for a long time in RHEL.

poetry is behaving as intended

I'm saddened to hear that poetry is intended to not work with most systems. Would you consider trying to use poetry in say, Ubuntu 18.04, a common environment which is broken under python3?

User experience should be valued in any tooling. Ultimately that is the purpose of tooling.

The proper solution here is to call python3 and python2 explicitly. It wouldn't break existing systems and it would solve the problem on affected configurations.

I would consider opening an issue, but the maintainers here have consistently shown ignorance to suggestions that they may not be right! Having read a lot of the community threads here, I also find some maintainers to be somewhat unfriendly to new contributors, which doesn't help.

I understand that there are other bugs, but if this is not considered a bug then pyenv should be listed as an explicit requirement for usage. I don't think discussion of the semantics of "bug" is particularly useful.

[dmontagu]

@trickeydan

As I said above:

But it does work on most distros; it just requires you to have an appropriately configured combination of python, poetry, and environment. This will always be a requirement.

---

I'm saddened to hear that poetry is intended to not work with most systems. Would you consider trying to use poetry in say, Ubuntu 18.04, a common environment which is broken under python3?

I am literally using poetry with vanilla Ubuntu 18.04 and python3 (3.7) right now. The only thing I had to do was make sure python points to python3 in the environment from which I call poetry.

In my experience using linux as a development platform, $PATH management like this is extremely common and to be expected.

(I found getting poetry to work with python 3.7 substantially easier than getting python 3.7 with pip installed on Ubuntu 18.04 in the first place.)

---

The proper solution here is to call python3 and python2 explicitly.

I'm not sure I understand.

Is your point that rather than using a shebang line to determine the python to use to call poetry, poetry should bootstrap itself by first inspecting the pyproject.toml and/or global configuration, and then re-call itself using the correct python? That sounds like it would add some meaningful complexity.

More generally, do you take issue with this comment? (To be clear, I could imagine agreeing with the substance of the comment, but still wanting a better user experience; I'm just looking for clarification.)

It wouldn't break existing systems and it would solve the problem on affected configurations.

If the shebang line no longer points to the environment python, wouldn't this result in existing systems potentially ending up broken if python is currently pointing at something different than what would be picked up by the updated version of poetry?

---

Don't get me wrong -- I'm really not just trying to be contrarian, and would advocate for a change that was strictly backward compatible (at least as long as it didn't add any substantial amount of complexity).

Sorry if I'm being dumb and a fully backwards compatible solution exists in the previous comments if I read between the lines a little harder; I just don't see how it would work though.

[trickeydan]

The proper solution here is to call python3 and python2 explicitly.

I'm not sure I understand.

Is your point that rather than using a shebang line to determine the python to use to call poetry, poetry should bootstrap itself by first inspecting the pyproject.toml and/or global configuration, and then re-call itself using the correct python? That sounds like it would add some meaningful complexity.

No, the shebang line specifies the version of python that poetry runs under. This should be considered separate to the version of python in the project that we are managing.

The calls to pip, and files in the project should be run under python2 if it is a python 2 codebase, or python3 if it's a python 3 codebase, regardless of the runtime that poetry is using.

More generally, do you take issue with this comment? (To be clear, I could imagine agreeing with the substance of the comment, but still wanting a better user experience; I'm just looking for clarification.)

I think that's an entirely reasonable decision. However the data for the runtime to use for the project is already in pyproject.toml

It wouldn't break existing systems and it would solve the problem on affected configurations.

If the shebang line no longer points to the environment python, wouldn't this result in existing systems potentially ending up broken if python is currently pointing at something different than what would be picked up by the updated version of poetry?

I think this comes back to system level python vs venv python. They can be different. From a brief read of the relevant parts of the codebase, we should be able to make this change without breaking anything.

Don't get me wrong -- I'm really not just trying to be contrarian, and would advocate for a change that was strictly backward compatible (at least as long as it didn't add any substantial amount of complexity).

Sorry if I'm being dumb and a fully backwards compatible solution exists in the previous comments if I read between the lines a little harder; I just don't see how it would work though.

I hope I've explained it a bit better now.

TL;DR;

Poetry can run under the system level python (or in a separate venv) to the python that the project is using. When making calls to pip and python for the project we can explicitly call the version that we need.

[dmontagu]

@trickeydan Would this work / require special handling if you had disabled the use of an environment in your global poetry config? (Via poetry config settings.virtualenvs.create false or the corresponding environment variable setting.)

[dmontagu]

Sorry, I thought about this more carefully. Is your suggestion to use this section of the pyproject.toml to determine which python command to use?

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

I see two potential problems:

1. What if both python2.7 and python 3.4+ are allowed? (I think sdispater called out this specific case in the comment above.)
2. What if the relevant system doesn't have python2/python3 on the path, and just python?

In general, using pythonX if only one of python 2/3 is supported under the pyproject.toml, and falling back to python if either 1) both versions are supported, or 2) the corresponding executable doesn't exist (but python does) seems reasonable to me.

---

That said, I feel like this is actually just a special case of a more general problem -- having multiple python environments on your system. While python2 vs python3 is probably the most common issue along these lines, the same issue exists with python3.6, python3.7, etc., and it feels like the python2 vs python3 issue will only become less of a problem over time.

I think the current approach of just forcing the python command to be properly configured (rather than trying to be smart about precisely which command to look for) is a relatively clean solution that simplifies poetry's implementation, and prevents the need to handle/maintain a not-insignificant number of edge cases.

But a PR that handled everything correctly and was relatively limited in scope would convince me this wasn't a problem. (Though obviously I'm not the person you need to convince 😅.)

[David-OConnor]

But it does work on most distros; it just requires you to have an appropriately configured combination of python, poetry, and environment. This will always be a requirement.

To me, it feels more like a configuration issue / user experience issue than a bug; sdispater (and several others) called it out as such above (as noted by @finswimmer above as well).

I think this hits the nail on the head. This concern is well-known, as there have been several issues posted about it over the last year or so. I've chosen to create a new project with a different philosophy instead of PRing this one due this design choice. Poetry's deliberately limited in scope, and makes assumptions about the user's environment. This has several advantages, but means it requires additional tools like pyenv, or config to work on some Operating systems (Like Ubuntu), and it may not behave the same way on different systems. That's a subective decision, not a bug.

Some issues that may come up:

• This appears by default on popular variants of Linux (I think you're less likely to encounter it in Windows, at least with Py2 vs Py3 concerns).
• It's not documented, and the relevant error messages don't point to the solution.
• Going from a clean system to a working Poetry setup is a multi-step, multi-tool process.
• Pyenv's instructions are poor, involve multiple steps, and it's unclear what operating systems it works on.
• It's not obvious that specifying a python version in pyproject.toml won't instruct Poetry to use the right one, if available.

I think these are more likely to be a concern for new users, or users who use different computers/OSes concurrently.

I would have attempted to fix this with PRs, but since this appears to be a deliberate decision vice a bug looking for a fix, reinvented some wheels in a new project, with an as-easy-and-simple-as-possible philosophy.

I believe there's a poetry env feature in a preview release that may address some of these concerns.

[sdispater]

Thanks to everyone involved for the discussion and overall feedback.

I understand that this is still a usability issue that needs to be improved. A first step towards that was the introduction of the env command and related subcommands (see #731) which are currently available in preview releases of the 1.0.0 version.

That being said, we still need to improve the initial bootstrapping of a Poetry-managed project by trying as much as possible to find a Python version compatible with the python property declared in the pyproject.toml file. The tricky point is that Poetry accepts a range of Python versions (like ~2.7 || ^3.5) which, while useful, makes some things more complex, like dependency resolution and Python version selection. That's the main reason I hold off implementing any kind of Python version management at the beginning of the project.

So, to make sure everyone is aware: I want to fix this before the 1.0.0 release. The way this will likely be done is by always selecting the latest python executable compatible with the python property:

• ^3.5 (or ~2.7 || ^3.5) will use python3 if it's available and compatible. If it's not available, Poetry will try python and use it if it's compatible. If that fails, Poetry will raise an error.
• ~2.7 will use python if it's available and compatible. If that fails Poetry will raise an error.
• The current executable used to invoke poetry will also be tried in any case and use it if it's compatible.

This should alleviate most of the pain some users are currently experiencing. And the env command is there to manage more fine-grained requirements people might have.

Note that this is the current idea, but that may change while actually implementing it.

[geryogam]

@sdispater Glad to see that you will make Poetry PEP 394 compliant (that is to say trying python, python2 and python3 according to the tool.poetry.dependencies.python property in the pyproject.toml file when implicitly creating a built-in virtual environment) like suggested by the specification of the first post in issue #1386! Thanks a lot.

~2.7 will use python if it's available and compatible. If that fails Poetry will raise an error.

I think you forgot to mention that python2 is tried before python (cf. the examples in the specification).

[sdispater]

This is now implemented (see #1477) and available in the latest beta release.

[quest4next]

Try this, it worked for me.
Before poetry command execute below pyenv command with your favourite python version( which you would have already installed through pyenv)
pyenv shell 3.7.4
Now poetry recognizes pyenv environment you want to use.

User P4nd4b0b3r1n0 pointed this in https://stackoverflow.com/questions/59810276/poetry-doesnt-use-the-correct-version-of-python

[jfaleiro]

Whatever it was, seems like the fix failed for Poetry version 1.0.5 with a ^3.7 dependency.

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

after

$ pyenv local 3.7.3                                                                         
$ pyenv versions                                                                            
  system                                                                                                                                                
* 3.7.3 (set by /Users/jfaleiro/gitrepos/orderbook/.python-version)                                                                                     
  miniconda3-4.7.12      

poetry fails with ImportError: cannot import name sha256 i.e. it is deciding on his own to use python2.

After a pyenv shell, however:

$ pyenv shell 3.7.3 
$ pyenv versions                                                                            
  system
* 3.7.3 (set by PYENV_VERSION environment variable)
  miniconda3-4.7.12                                          

poetry finds the correct version.

[ajslater]

After upgrading macOS homebrew to python 3.8 today, poetry started displaying the bad/weird behavior mentioned in these reports. Poetry itself was installed with pip3 as a python 3.8 site-package and executes running the python3.8 interpreter, but seems to select only the python2.7 system interpreter to use for checking dependencies.

This solved it:

poetry env use python3

Seems like poetry doesn't know about about the python3 command on macOS/homebrew unless told about it.

[tastyminerals]

Jesus Christ. How long can this issue be alive? It is 2021 already.
Recently migrated to Mac only to google this out because poetry refuses to build a cloned project that successfully builds on Linux. And it breaks because it tries to install the dependencies for python2! while the project uses python3.8, wtf.
All this just when I was planning to introduce poetry to the team this spring. Was.

[AlexanderFarkas]

@ajslater You probably should have upgraded python version in pyproject.toml for it to work.

[github-actions]

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.