Poetry install localstack['runtime'] fails

[orientalperil]

• 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: Mac 10.15.6
• Poetry version: 1.1.13
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/orientalperil/0bf3229601e34a4c3e9484f748fd5278

Issue

Poetry runs dependency resolver forever when I run poetry add localstack['runtime']

[dimbleby]

It looks as though poetry's first attempt at a solution is in some way incompatible with awscli - and that it sits there working through the many hundreds of versions of awscli, failing to find one that is compatible. This seems to cause it to build up such a huge number of constraints that it kinda grinds to a halt.

I was able to get to a solution in reasonable time by first adding an explicit dependency on a recent awscli, that seems to be enough to send poetry down a path that's not a dead end. However that also ran into #4683...

[abn]

Resolved by #5335

[dimbleby]

This is not resolved by #5335 - that MR improves things, but still localstack['runtime'] is uninstallable without hints about picking a recent awscli

[abn]

I think the fix here is to constrain awscli together with the PR to get a more reasonable solving time. The add did succeed for me after an hour or so. :(

Doubt these cases will ever be improved with the metadata currently available.

[dimbleby]

it's not really about the metadata (though it does help when that is available). As best I recall from when I looked at this at #5335-time, we end up building Term objects with massively elaborate constraints, and then operations to compare those constraints become expensive. It's 100% CPU-bound computation that is the bottleneck, not downloading and inspecting wheels.

I don't have great ideas about how to reorganise the data structures to fix this and you may be right that it will never get improved. I might or might not have another think about it some day...

Personally I'd have left this open so that we acknowledge that it's still a problem, and maybe someone else will see it and feel like doing something about it. But no big deal I guess.

[abn]

I agree that this will need to be looked at in more detail. My recommendation there would be to open a new issue specific for this class of issue with the solver. Atleast, this way people who get to this issue with the same package has a clear mitigation and a link to a more deeper dive issue.

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