Because you can’t do any real testing of GHC without putting head.hackage into your cabal.project, but we want people to actually trial alphas, to get enough feedback about regressions and other issues, that could be addressed leading up to the proper release.
Adding head.hackage to your cabal.project is easy, removing it requires someone to notice and be bothered enough to actually go and remove it. The next person sees head.hackage fixing some build issues and keeps cargo culting it along.
What breaks it, I guess it’s often template-haskell. It could be in-flight changes in GHC (perfectly fine), or GSC / CLC changes.
@RyanGlScott highlights some good usecases.
The main
head.hackage
use case is making it easier to build Hackage libraries with pre-release or HEAD versions of GHC.
My argument is it should be exclusively required for HEAD versions of GHC. And there it’s perfectly fine.
If we end up putting head.hackage into all kinds of cabal.projects people will end up depending on it, cargo cult it further, and any changes to it will then lead to surprising behaviour (because people shouldn’t have been using head.hackage in the first place).