Consumer passes in a prepare method which is called over backtrack causes

[jbylund]

Add a prepare attribute to the Resolution object which is called on backtrack causes before passing that to _get_preference. This allows providers to operate over a processed version of backtrack_causes without having to implement a cache consumer side (which can be "yucky").

[jbylund]

@notatallshaw this is the other possibility I mentioned. Let me know if you think this would mesh well with your ideas for backtracking in the future?

[notatallshaw]

This approach LGTM if maintainers want the logic of processing the causes to remain on the downstream library side.

And I continue to really prefer avoiding a cache that depends on the ids of mutable objects (even if they are carefully used).

I guess let's just see what maintainers think.

[uranusjr]

I think #93 would supercede this now?

[jbylund]

I think #93 would supercede this now?

My opinion is that this option would allow for:

• the possibility of a simpler solution making use of stdlib collection types - class is reduced to a function which returns a set
• more separation/flexibility between different consumers of resolvelib - users that might care about the order of conflicts (I don't even know if that could theoretically matter to someone) could choose the passthrough method

[uranusjr]

Sounds like a provider function is also a fit for those reasons? If the consumer wishes, it can simply implement the function to return a set, or whatever built-in or custom type that suits the need.

[jbylund]

Sounds like a provider function is also a fit for those reasons? If the consumer wishes, it can simply implement the function to return a set, or whatever built-in or custom type that suits the need.

But I think we need this "hook" to allow the provider to inject such a function?

[jbylund]

The pip side of this change would be this.