Fix fallback to other interpreters when specifying a patchlevel.

[jaharkes]

When a project specifies a narrow range for the supported python
versions, i.e. "python ~= 3.6.1" and the current interpreter falls
outside of that range, the fallback code fails to test an available
python3.6 interpreter because of a too strict a test.

Pull Request Check List

Resolves: #3463

• Added tests for changed code.
• [N/A] Updated documentation for changed code.

[jaharkes]

I guess I should elaborate, I hit this when I upgraded my Ubuntu system from 18.04 to 20.04.

The upgrade switched the default python interpreter to 3.8 and the project I was working on had a dependency that was only available for python<3.8. And to add to the fun, another dependency claimed to only support python>=3.6.1.

So I installed python-3.6.12 from the deadsnakes ppa and switched the dependency from python = "^3.6.1" to python = "~3.6.1". But poetry complained it didn't find a compatible version. However when I specify "~3.6" it does find the installed python3.6 binary, but then complains later on that the "current project's Python requirement (>=3.6,<3.7) is not compatible with some of the required packages Python requirements".

Some debugging later, I found that when it is looking for the version of installed python interpreters there is an optimization that skips running interpreters that do not fall in the requested range of supported python versions. And, as is, the test runs if not Version(">=3.6.1,<3.7").allows_all("3.6.*"): which happens to be true because the constraint doesn't allow for version 3.6.0 and so it never bothers to even check if the actual version of the installed python-3.6.12 is acceptable.

[sonarcloud]

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
3.5% Duplication

[jaharkes]

I'm just rebasing this PR periodically and make sure all the tests still work locally with tox.

Right now I'm locally getting a type error from the python3.7 tests, which is also present in the upstream version without my patch. Also for some reason sonarcloud seems to be complaining about code duplication in test_env.py, but in a part of the file unrelated to the modifications from this patch.

The PR has been waiting for review since December, is there anything I can do to help it make progress?

[jaharkes]

ping @python-poetry/triage

In my environment, I have multiple python version installed locally, The default python3 interpreter is 3.8.10 but I also have python-3.6.15. The following pyproject.toml is unable to find the 3.6.15 interpreter without this patch.

[tool.poetry]
name = "python_version"
version = "0.1.0"
description = ""
authors = ["test <test@example.org>"]

[tool.poetry.dependencies]
python = ">=3.6.5,<3.7"

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

Without patch

$ poetry shell
The currently activated Python version 3.8.10 is not supported by the project (>=3.6.5,<3.7).
Trying to find and use a compatible version. 

  NoCompatiblePythonVersionFound

  Poetry was unable to find a compatible version. If you have one, you can explicitly use it via the "env use" command.

With patch

$ poetry shell
The currently activated Python version 3.8.10 is not supported by the project (>=3.6.5,<3.7).
Trying to find and use a compatible version. 
Using python3.6 (3.6.15)
Creating virtualenv python-version-avkAwIfu-py3.6 in /home/.../.cache/pypoetry/virtualenvs
Spawning shell within /home/.../.cache/pypoetry/virtualenvs/python-version-avkAwIfu-py3.6

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.