You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
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.
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.
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.
Activity
dimbleby commentedon Mar 13, 2022
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 commentedon Apr 8, 2022
Resolved by #5335
dimbleby commentedon Apr 8, 2022
This is not resolved by #5335 - that MR improves things, but still
localstack['runtime']is uninstallable without hints about picking a recent awscliabn commentedon Apr 9, 2022
I think the fix here is to constrain
awsclitogether 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 commentedon Apr 10, 2022
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 commentedon Apr 10, 2022
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 commentedon Mar 2, 2024
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.