I think it’s a shame that the GHC.X.hackage proposal didn’t get more traction, I thought it was a good idea. One suggestion I made at the time that Moritz might like was that we could potentially sunset a GHC.X.hackage repository after some time period, which would give people a good incentive to get off it as quickly as possible.
head.hackage
is a pool of patches from different authors and I as an end-user have no easy way of knowing whether those patches are…
Another idea that occurs to me is that maybe we could make the information that head.hackage
packages are not created by the maintainers visible to cabal. Imagine, say, an “unofficial” metadata tag that could be attached to package versions; then we could have controls in cabal to allow these, or allow them only for certain packages, etc. That would allow you to only fetch unofficial packages from head.hackage
that you actually need, rather than allowing just anything that might be in there. E.g. allow-unofficial:text
would allow cabal to pick an unofficial version of text
and only text
.
(Alternatively, some kind of finer-grained way of specifying which packages can be resolved from which repositories? active-repositories: hackage, head.hackage(text)
?)
I’m not sure how exactly in-place updates to remote project files work.
Any solution here is going to be stateful: at least you need to add new patches from time to time. head.hackage
is a cabal package repository and at least makes that statefulness explicit. In particular it can in principle support index-state
(there’s a PR to use @andreabedini 's foliage
tool which would enable that), which means that you can use it reproducibly. Having a project file that was updated in place loses the ability to control the state there, which seems worse to me.
Well, I don’t know personally, but @angerman thinks it’s not only happening, but happening so much that it is lowering the quality of the ecosystem.
I will note that I have only very rarely seen head.hackage
used in the wild. The cases I can think of are:
- HLS has sometimes used it, but HLS tries very hard to get something that works with a new GHC quickly. We are also very proactive at getting rid of such things - we really want HLS to be installable just from Hackage.
- This is a problematic usage! If we build HLS binaries with
head.hackage
then we are exposing end-users to any questionable stuff in the head.hackage
patches, not just developers! So I’m not super happy about this actually.
- Some IOG things have used it, but again I think that’s mostly been a consequence of e.g. trying to use very new GHCs in
haskell.nix
.