Only backjump if the current broken state is an incompatible dependency

[notatallshaw]

This appears to fix backjumping, in all cases, while keeping the performance benefits.

I do not have an intuitive explanation, but I created a series of tests and printed out debugging information and looked at when the current backjumping made the wrong choice, and it was always when the current broken state's name was not in the incompatible dependencies.

I have added two tests that currently fail that I constructed from my understanding of when the problem occurs.

I have created another test, not in this PR, based on kedro[test]==0.18.13, however the JSON is massive (450k lines), and it would require a better get_preference to complete in a reasonable number of rounds. Let me know if you want me to try and get that test working for this or another PR.

[frostming]

This looks a great and neat fix. I am willing to have this merged, @uranusjr @pradyunsg

[notatallshaw]

FYI, I'm still trying to wrangle kedro into a test, but it might take a while, I'm off on vacation Wednesday evening. I see no problem landing it in another PR though.

[notatallshaw]

Thanks!

I was just about to commit some new tests, new PR coming in a minute

[pradyunsg]

Sounds good -- this change looks fine, and I think I can reason about it being correct?

[notatallshaw]

I think I can reason about it being correct?

I'm going to be honest, I can not, it was never clear to me that backjumping was proven correct within resolvelib. I only found this by very carefully looking at the paths taken with and without backjumping in these minimal examples and looking at the variables when it appeared to take the wrong path.

So my plan is examples and tests:

• Real world example kedro[test]==0.18.1 now resolves correctly
• Added test cases here that are fixed by this
• Opened a separate PR that shows backjumping is still skipping unnecessary paths