Joseph Bylund
Joseph Bylund
Or maybe just move it to be the last option on the list?
@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?
> 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...
> 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...
The pip side of this change would be [this](https://github.com/pypa/pip/compare/main...jbylund:joe/use_prepare_on_provider).
Put the finder into a public attribute so avoid accessing a private attribute. What do you see as the options for not relying on the caching behavior of find_all_candidates? Re:...
> One simple solution would be to implement a cache layer on the factory (e.g. a `Factory.find_all_candidates()` wrapper). If parallisation is available, the wrapper would populate the cache with imap...
Not ready for merge, but not sure if draft prs are just hidden from review queue.
I think the way in which this is different is that the resolver never calls `find_all_candidates` except via `find_best_candidates`? so unless the package finder's `find_best_candidate` is implemented by using `find_all_candidates`...
How about adding a test to the finder which demonstrates that calling `find_best_candidate` after calling `find_all_candidates` results in a cache hit?