stackage-curator should have option to explain where broken deps are coming from
juhp opened this issue · 5 comments
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.
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.
Hmm... let me actually play with it a moment, maybe it's not so bad.
OK, maybe this will address all the common use cases. I've pushed a new list-revdeps
command, want to give it a shot?
Thank you that's useful.
I just tried it now and it seems to work well.
👍