stackage-curator should have option to explain where broken deps are coming from

[juhp]

Twice this week I had to track down broken deps caused by some package update adding a new dep to a package which currently does not build in Stackage Nightly. It would be really nice if stackage-curator could show what packages are pulling in such breakage.

The two incidents were

• path's testsuite now needing genvalidity* which could not build - now fixed hopefully (stackage curator just showed broken bounds for genvalidity and genvalidity-hspec)
• today datasets pulling in wreq (curator just complains that wreq can't build)

The former was not so hard to track down with revdeps, but I had to go into all-cabal-hashes to hunt down the latter.

[snoyberg]

I'm hesitant to try adding this functionality to stackage-curator, as it's somewhat tricky to predict all pieces of information that would be desired. I typically resolve this by looking directly at the build-plan.yaml file, which lists the users of each package.

[snoyberg]

Hmm... let me actually play with it a moment, maybe it's not so bad.

[snoyberg]

OK, maybe this will address all the common use cases. I've pushed a new list-revdeps command, want to give it a shot?

[juhp]

Thank you that's useful.
I just tried it now and it seems to work well.

[snoyberg]

👍