questions about head.hackage

Hello everyone, For the stability working group I'm trying to understand how many packages head.hackage allows you to build. Does anyone know the answer to this or have an idea how I can find out? For context, the stability working group is a group of interested people who try and allow ghc and haskell system to innovate, while reducing the amount of friction caused to the wider Haskell community. Current efforts include the marking language proposals as stable, and my work of investigating historic breakage. Investigating this breakage will allow us to make better informed decisions on which pain points to prioritize. -- With regards, Jappie Klooster e: hi@jappie.me w: https://jappie.me m: +31644237437

Hi Jappie,
This answer will only tangentially answer your question. Head hackage by
design is GhC development internal and should never ever leak out of ghc
development. As such the packages building with it today may not build
tomorrow (ghc HEAD is a moving target).
What you _can_ do is look at the package patches in head.hackage; and the
look at the dependencies for them in hackage to get a rough estimate of
direct and indirect packages being enabled.
Getting an accurate count would require trying to compile all hackage
against some ghc from master. And that number likely changes every day due
to head of ghc and hackage being moving targets. L
A more sensible option might be to try and use a subset like stackage or
the CLC stackage set to buidl against.
Best, Moritz.
On Tue, 23 Jul 2024 at 8:39 AM, jappie klooster
Hello everyone,
For the stability working group I'm trying to understand how many packages head.hackage allows you to build. Does anyone know the answer to this or have an idea how I can find out?
For context, the stability working group is a group of interested people who try and allow ghc and haskell system to innovate, while reducing the amount of friction caused to the wider Haskell community. Current efforts include the marking language proposals as stable, and my work of investigating historic breakage. Investigating this breakage will allow us to make better informed decisions on which pain points to prioritize.
-- With regards,
Jappie Klooster
e: hi@jappie.me w: https://jappie.me m: +31644237437 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Tue, 23 Jul 2024, at 7:38 AM, jappie klooster wrote:
For the stability working group I'm trying to understand how many packages head.hackage allows you to build. Does anyone know the answer to this or have an idea how I can find out?
I don't have the numbers you are looking for but one data-point is that cabal-install itself (which has a reasonable number of dependencies) typically does not compile with a freshly released GHC. This forces to temporarily add head.hackage in CI when a new GHC releases. IMHO, using head.hackage to test a source-distribution defeats the purposes of testing. We cannot (and should not) assume those building cabal's source distribution(s) are using it, and therefore `cabal install cabal-install` will end up succeeding in our CI and failing for everybody else. My 2c, Andrea -- Andrea Bedini https://www.andreabedini.com

Hi Jappie,
There is a GHC grafana with some statistics. Unfortunately the relevant
dashboards seem to be broken at present. Hopefully someone on this list
could fix it.
See:
https://grafana.gitlab.haskell.org/d/7T7oEMlMz/head-hackage-performance?orgId=2&viewPanel=3
There's also
https://grafana.gitlab.haskell.org/d/RHebDhq7z/head-hackage-residency-profiling?orgId=2&refresh=30m,
which is for residency information, but looking at the filters suggests
that the peak amount of packages is around 900.
Cheers,
Teo
On Tue, Jul 23, 2024 at 4:29 AM Andrea Bedini
On Tue, 23 Jul 2024, at 7:38 AM, jappie klooster wrote:
For the stability working group I'm trying to understand how many packages head.hackage allows you to build. Does anyone know the answer to this or have an idea how I can find out?
I don't have the numbers you are looking for but one data-point is that cabal-install itself (which has a reasonable number of dependencies) typically does not compile with a freshly released GHC. This forces to temporarily add head.hackage in CI when a new GHC releases.
IMHO, using head.hackage to test a source-distribution defeats the purposes of testing. We cannot (and should not) assume those building cabal's source distribution(s) are using it, and therefore `cabal install cabal-install` will end up succeeding in our CI and failing for everybody else.
My 2c, Andrea
-- Andrea Bedini https://www.andreabedini.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thanks Teo, that's exactly what I was looking for I'll keep in mind this number changes over time. @Andrea I think the intention is that the patches eventually get upstreamed to the libraries It's just a good measure point for me to do quantitative breakage analysis upon. On 23-07-2024 03:06, Teofil Camarasu wrote:
Hi Jappie,
There is a GHC grafana with some statistics. Unfortunately the relevant dashboards seem to be broken at present. Hopefully someone on this list could fix it. See: https://grafana.gitlab.haskell.org/d/7T7oEMlMz/head-hackage-performance?orgId=2&viewPanel=3 https://grafana.gitlab.haskell.org/d/7T7oEMlMz/head-hackage-performance?orgId=2&viewPanel=3
There's also https://grafana.gitlab.haskell.org/d/RHebDhq7z/head-hackage-residency-profiling?orgId=2&refresh=30m https://grafana.gitlab.haskell.org/d/RHebDhq7z/head-hackage-residency-profiling?orgId=2&refresh=30m, which is for residency information, but looking at the filters suggests that the peak amount of packages is around 900.
Cheers, Teo
On Tue, Jul 23, 2024 at 4:29 AM Andrea Bedini
wrote: On Tue, 23 Jul 2024, at 7:38 AM, jappie klooster wrote: > For the stability working group I'm trying to understand how many > packages head.hackage allows you to build. > Does anyone know the answer to this or have an idea how I can find out?
I don't have the numbers you are looking for but one data-point is that cabal-install itself (which has a reasonable number of dependencies) typically does not compile with a freshly released GHC. This forces to temporarily add head.hackage in CI when a new GHC releases.
IMHO, using head.hackage to test a source-distribution defeats the purposes of testing. We cannot (and should not) assume those building cabal's source distribution(s) are using it, and therefore `cabal install cabal-install` will end up succeeding in our CI and failing for everybody else.
My 2c, Andrea
-- Andrea Bedini https://www.andreabedini.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- With regards, Jappie Klooster e:hi@jappie.me w:https://jappie.me m: +31644237437
participants (4)
-
Andrea Bedini
-
jappie klooster
-
Moritz Angermann
-
Teofil Camarasu