Make it possible (for a reporter) to determine which candidate a requirement originates from

[pradyunsg]

This would be useful for reporters, to determine why a certain requirement is added.

I'm imagining a evaluating hook, that's called at the start of the loop on _attempt_to_pin_criterion, prior to pinning but unconditionally (so that it doesn't actually have to match the criterion).

As an example, I want to be able to visualize false-starts / not-compatible-version checks, before they're pinned and currently, there's no way for the reporter to get this information.

[pradyunsg]

an hard-coded assumption that pinning would be called after adding_requirement

Actually, this doesn't work for "root" requirements (workaround: have logic to look at whether starting was called), or for candidates that get evaluated but not pinned (useful for showing mismatches / failures).

[pradyunsg]

Alternatively, we could add a evaluating hook, that's called at the start of the loop on _attempt_to_pin_criterion.

diff --git a/src/resolvelib/resolvers.py b/src/resolvelib/resolvers.py
index 157eefa..60cdb32 100644
--- a/src/resolvelib/resolvers.py
+++ b/src/resolvelib/resolvers.py
@@ -218,6 +218,7 @@ class Resolution(object):
     def _attempt_to_pin_criterion(self, name, criterion):
         causes = []
         for candidate in reversed(criterion.candidates):
+            self._r.evaluating(candidate)
             try:
                 criteria = self._get_criteria_to_update(candidate)
             except RequirementsConflicted as e:

That'd make the order-of-relevant-reporter-hook-calls:

calling resolve
  adding  ('A', <SpecifierSet('>=1.0')>)
starting
eval      ('A', <Version('3.0.0')>)
  adding  C==2.0.0
  adding  B==3.0.0
  pin     ('A', <Version('3.0.0')>)
eval      ('C', <Version('2.0.0')>)
  pin     ('C', <Version('2.0.0')>)
eval      ('B', <Version('3.0.0')>)
  adding  C==3.0.0
backtrack ('C', <Version('2.0.0')>)
backtrack ('A', <Version('3.0.0')>)
eval      ('A', <Version('2.0.0')>)
  adding  C==1.0.0
  adding  B==2.0.0
  pin     ('A', <Version('2.0.0')>)
eval      ('C', <Version('1.0.0')>)
  pin     ('C', <Version('1.0.0')>)
eval      ('B', <Version('2.0.0')>)
  adding  C==2.0.0
backtrack ('C', <Version('1.0.0')>)
backtrack ('A', <Version('2.0.0')>)
eval      ('A', <Version('1.0.0')>)
  adding  B==1.0.0
  pin     ('A', <Version('1.0.0')>)
eval      ('B', <Version('1.0.0')>)
  adding  C==1.0.0
  pin     ('B', <Version('1.0.0')>)
eval      ('C', <Version('1.0.0')>)
  pin     ('C', <Version('1.0.0')>)

To:

calling resolve
  adding  ('A', <SpecifierSet('>=1.0')>)
starting
  adding  C==2.0.0
  adding  B==3.0.0
  pin     ('A', <Version('3.0.0')>)
  pin     ('C', <Version('2.0.0')>)
  adding  C==3.0.0
backtrack ('C', <Version('2.0.0')>)
backtrack ('A', <Version('3.0.0')>)
  adding  C==1.0.0
  adding  B==2.0.0
  pin     ('A', <Version('2.0.0')>)
  pin     ('C', <Version('1.0.0')>)
  adding  C==2.0.0
backtrack ('C', <Version('1.0.0')>)
backtrack ('A', <Version('2.0.0')>)
  adding  B==1.0.0
  pin     ('A', <Version('1.0.0')>)
  adding  C==1.0.0
  pin     ('B', <Version('1.0.0')>)
  pin     ('C', <Version('1.0.0')>)

[uranusjr]

I don’t like having too many hooks being called for a given code path. Would it be okay if a hook is added to report a candidate does not match? (i.e. for each candidate, either pinning or ignoring is called). Or maybe we can just renaming the pinning hook to something like tried_to_pin(candidate: Candidate, success: bool) and call it before the continue.

[techalchemy]

Or maybe we can just renaming the pinning hook to something like tried_to_pin(candidate: Candidate, success: bool)

I for one prefer this option, fwiw, since the naming is a lot easier to understand - although I can see the advantage of having two completely separate calls as well to avoid having to embed the conditional logic in the reporter.

[pradyunsg]

The other option is to add a parent argument to Reporter.adding_requirement -- the call site has the relevant information available to it.

[pradyunsg]

Or maybe we can just renaming the pinning hook to something like tried_to_pin(candidate: Candidate, success: bool) and call it before the continue.

This doesn't make it possible to have all the information about which candidate the requirement originated from (see adding C==3.0.0 in the aforementioned output, which originates from ('B', <Version('2.0.0')>)).

[uranusjr]

I can always pass in the requirements as well. How about

tried_to_pin(requirements: List[Requirement], candidate: Optional[Candidate])

where candidate would be None on a failed pin?

[pradyunsg]

@uranusjr What would List[Requirement] be?

[uranusjr]

The requirements that the resolver tried to find the intersection on. But now I see that’s not what you want, but parent from the criteria?

I think I’ll go with the parent in adding_requirement() solution. That is the most straightforward conceptually for me. It’s getting muddy what exactly are needed right now, so many options have been proposed. Would you mind creating a PR adding the needed hooks for this solution?