poetry fails to resolve constraints of both python and markers

[bentheiii]

• 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: windows/linux (reproduced both in windows and WSL)
• Poetry version: 1.1.4
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/bentheiii/4a54c1d59fe40eb87dbe31711fdf8f8f

Issue

The toml file provided fails to lock, due to a version conflict on pytype and python. The message is:

  The current project's Python requirement (>=3.7,<4.0) is not compatible with some of the required packages Python requirement:
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.5, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.6, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.6, so it will not be satisfied for Python >=3.9,<4.0
    - pytype requires Python <3.9,>=3.6, so it will not be satisfied for Python >=3.9,<4.0

  Because no versions of pytype match >2020.06.01,<2020.6.26 || >2020.6.26,<2020.7.14 || >2020.7.14,<2020.7.20 || >2020.7.20,<2020.7.24 || >2020.7.24,<2020.7.30 || >2020.7.30,<2020.8.10 || >2020.8.10,<2020.8.17 || >2020.8.17,<2020.8.28 || >2020.8.28,<2020.9.14 || >2020.9.14,<2020.9.16 || >2020.9.16,<2020.9.24 || >2020.9.24,<2020.9.29 || >2020.9.29,<2020.10.8 || >2020.10.8,<2020.11.3 || >2020.11.3,<2020.11.12 || >2020.11.12,<2020.11.23 || >2020.11.23
   and pytype (2020.6.1) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.6.26) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.7.14) requires Python <3.9,>=3.5
   and pytype (2020.7.20) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.7.24) requires Python <3.9,>=3.5
   and pytype (2020.7.30) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.8.10) requires Python <3.9,>=3.5
   and pytype (2020.8.17) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.8.28) requires Python <3.9,>=3.5
   and pytype (2020.9.14) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.9.16) requires Python <3.9,>=3.5
   and pytype (2020.9.24) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.9.29) requires Python <3.9,>=3.5
   and pytype (2020.10.8) requires Python <3.9,>=3.5, pytype is forbidden.
  And because pytype (2020.11.3) requires Python <3.9,>=3.6
   and pytype (2020.11.12) requires Python <3.9,>=3.6, pytype is forbidden.
  So, because pytype (2020.11.23) requires Python <3.9,>=3.6
   and dyndis depends on pytype (>=2020.06.01), version solving failed.

running also printed For pytype, a possible solution would be to set the python property to ">=3.7,<3.9", which suggests that poetry is ignoring the python property altogether (since that is the property's current value).

The file locks properly if I erase the markers property, or set it to an empty string.

[mrosales]

As a note, this also seems to work if you specify an environment marker constraint on the python version instead of using poetry's python option for the dependency:

What you have in your snippet doesn't seem to work:

[tool.poetry.dev-dependencies]
pytype = { version = ">=2020.06.01", python = "<3.9", markers = "platform_system != 'Windows'"}

But moving the version constraint to the marker seems to work:

[tool.poetry.dev-dependencies]
pytype = { version = ">=2020.06.01", markers = "python_version < '3.9' and platform_system != 'Windows'"}

It seems like poetry might be ignoring the python constraint if markers is also specified.

[maciejskorski]

The following test confirms that poetry does not populate python constraints due to markers

[tool.poetry.dependencies]
python = "3.8"
pandas = [
    {version="1.3.2",python="3.9",markers="sys_platform=='linux'"},
    {version="1.3.1",python="3.8"}
]

then setting a breakpoint inside complete_package method gives

# [(d.name+str(d._constraint),d._python_constraint) for d in requires]
[('pandas1.3.2', <VersionRange (*)>), ('pandas1.3.1', <Version 3.8>)]

[maciejskorski]

@mrosales moving inside markers may have a side effect on performance, by preventing early version validation - and thus make resolving slower.

[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.