Skip to content

Option to only provide causes of conflict when calling get_preference #131

@notatallshaw

Description

@notatallshaw

When #84 was implemented it gave the downstream library the information about whether something was the cause of a backtracking conflict or not.

However using this information is problematic from a performance perspective as it can create an O(n2) situation as the entire list of names is checked over and for each name the entire list of backtrack causes is checked over. Although in most cases n is small enough that it's negligible, it has created real world performance issues (pypa/pip#10621).

There have been of a couple of unmerged PRs to attempt to fix this via either by doing some fancy caching logic in Pip or defining a formal object structure for what a "Cause" object should look like and then add cache on to that object.

However a much simpler solution is to take the implicit loop out of get_preference and when there is a conflict for resolvelib to only pass names to the downstream library that are part of the backtrack cause. It seems to be this information is sufficiently generic for a resolving library that it can be an option of the algorithm itself and not just a preference of the downstream library.

I will start to make a PR and see how it performs, I opened this issue now to see if there is any direct objections to this approach.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions