New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
juhp opened this Issue Dec 10, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@juhp
Contributor

juhp commented Dec 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Dec 11, 2016

Member

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.

Member

snoyberg commented Dec 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Dec 11, 2016

Member

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

Member

snoyberg commented Dec 11, 2016

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

snoyberg added a commit that referenced this issue Dec 11, 2016

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Dec 11, 2016

Member

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

Member

snoyberg commented Dec 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@juhp

juhp Dec 13, 2016

Contributor

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

Contributor

juhp commented Dec 13, 2016

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

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Dec 13, 2016

Member

👍

Member

snoyberg commented Dec 13, 2016

👍

@snoyberg snoyberg closed this Dec 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment