Non idempotent resolve via poetry lock and poetry update

[DriverX]

• 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:

$ uname -a
Linux a-ilyushenkov 4.19.121-linuxkit #1 SMP Thu Jan 21 15:36:34 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

• Poetry version:

$ poetry --version
Poetry version 1.1.5

• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/DriverX/a6a7525ae246f3073ff7076ca0501d5d

Issue

Resolve operation in poetry lock and poetry update is not idempotent.
I have two dependencies in my pyproject.toml (see gist): idna and request.

poetry lock resolve

$ poetry lock && poetry install
Updating dependencies
Resolving dependencies... (8.0s)

Writing lock file
Installing dependencies from lock file

Package operations: 0 installs, 2 updates, 0 removals

  • Updating idna (2.10 -> 3.1)
  • Updating requests (2.25.1 -> 2.15.1)

poetry update resolve invariant

$ poetry update
Updating dependencies
Resolving dependencies... (1.9s)

Writing lock file

Package operations: 0 installs, 2 updates, 0 removals

  • Updating idna (3.1 -> 2.10)
  • Updating requests (2.15.1 -> 2.25.1)

More stranger the order of the dependencies matters. This spec poetry lock and poetry update resolve identically.

[tool.poetry.dependencies]
python = ">=3.6.5, <4"
requests = "*"
idna = "*"

  • Updating idna (2.10 -> 3.1)
  • Updating requests (2.25.1 -> 2.15.1)

[TBBle]

Probably a duplicate of #3551. If not, then my comments on that issue belong here. But I'm pretty sure they're the same thing: "poetry update chooses a different "best resolution" when upgrading this requests/idna pairing".

The "order of dependencies" observation is probably highly relevant to the issue.

[dimbleby]

As well as #3551 this is also a duplicate of #2883: and as in that issue I think this isn't a bug.

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