Skip to content

Poetry install localstack['runtime'] fails #5217

Closed

Description

@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).

Issue

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

Activity

  1. dimbleby commented on Mar 13, 2022

    @dimbleby
    Contributor

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

  2. added
    area/solverRelated to the dependency resolver
    and removed
    status/triageThis issue needs to be triaged
    on Apr 8, 2022
  3. abn commented on Apr 8, 2022

    @abn
    Member

    Resolved by #5335

  4. dimbleby commented on Apr 8, 2022

    @dimbleby
    Contributor

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

  5. abn commented on Apr 9, 2022

    @abn
    Member

    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.

  6. dimbleby commented on Apr 10, 2022

    @dimbleby
    Contributor

    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.

  7. abn commented on Apr 10, 2022

    @abn
    Member

    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.

  8. github-actions commented on Mar 2, 2024

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

  9. locked as resolved and limited conversation to collaborators on Mar 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/solverRelated to the dependency resolverkind/bugSomething isn't working as expected

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions