Release 1.1.6

[sdispater]

Fixed

• Fixed export format for path dependencies. (#3121)
• Fixed errors caused by environment modification when executing some commands. (#3253)
• Fixed handling of wheel files with single-digit versions. (#3338)
• Fixed an error when handling single-digit Python markers. (poetry-core#156)
• Fixed dependency markers not being properly copied when changing the constraint leading to resolution errors. (poetry-core#163)
• Fixed an error where VCS dependencies were always updated. (#3947)
• Fixed an error where the incorrect version of a package was locked when using environment markers. (#3945)

[abn]

Looks like we need to drop the importlib-resources upgrade https://github.com/python-poetry/poetry/pull/3905/files#diff-f53a023eedfa3fbf2925ec7dc76eecdc954ea94b7e47065393dbad519613dc89R376.

[sdispater]

@abn It should not fail since markers are present and correct. I'll investigate but for now I will hold off the release.

[sdispater]

@abn I think we are hitting a limit of the current resolver. And I don't see a simple solution to this issue.

I am surprised we did not hit this sooner but basically the issue comes from these two dependencies:

virtualenv = { version = "^20.0.26" }
pre-commit = { version = "^2.6", python = "^3.6.1" }

The resolver chooses to resolve pre-commit first: version 2.10.1 requires Python >= 3.6.1 and depends on importlib-resources (*) ; python_version < \"3.7\". That works for the resolver and it selects importlib-resources (5.1.2) which requires Python >= 3.6.

The resolver then resolves virtualenv which requires importlib-resources (>=1.0) ; python_version < \"3.7\". But the resolver in its current version assumes that importlib-resources (5.1.2) satisfies this constraint, which is only the case for Python >=3.6.1.

[sdispater]

Well I may have a workaround it seems by prioritizing dependencies without markers first. This is not a silver bullet though and we might need to improve this part of the resolver.

[abn]

IIUC, sounds almost like the resolver needs to keep the resolution context around from the previous result. In this case, knowing that importlib-resources (5.1.2) was resolved for >=3.6 should mean we resolve again for the difference right? This should essentially lead us to two different versions with mutually exclusive python version constraints.

[sdispater]

@abn I tried something similar but that did not lead anywhere due to the way the resolver is structured, or it led to severe performance issues.

The workaround (#3944) should alleviate – and actually fix in most cases – the issue.

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