Remove index state

[hasufell]

Index state in master makes things more complicated for end users to test (this is the case for 9.6.7-rc2).

It is not maintained properly either and is over 2 months old.

It's better to:

• maintain correct dependency bounds
• possibly introduce index state for release branches

[michaelpj]

Can you explain why this is problematic for you? Including the index-state makes the repository reproducibly buildable (including historically) and allows people to reliably compile it on their own computers without relying on us getting all the bounds right (which we won't),

[hasufell]

Can you explain why this is problematic for you?

ghcup compile hls -g master --ghc 9.6.7.20250131 fails, because it doesn't pick up the fixed ghc-lib-parser-9.8.5.20250214.

This is what happens with index state. You make it "reproducible" (which is actually not true) for past configurations only.

[michaelpj]

This is what happens with index state. You make it "reproducible" (which is actually not true) for past configurations only.

It's a hell of a lot more reproducible in a way that is practically valuable. This is the first time in a long time I've heard anyone complain about not being able to build HLS due to solver issues. It works!

ghcup compile hls -g master --ghc 9.6.7.20250131 fails, because it doesn't pick up the fixed ghc-lib-parser-9.8.5.20250214.

Okay, so the situation is:

• We have a new GHC that we don't officially support
• Someone is trying to build HLS off master, which is always a little risky
  • Note that you propose putting index-state on release branches, which would preclude this ever working on actual releases
• The new GHC forces a new version of a non-reinstallable library, which either was not released at the time or requires a new version of some other library that was not released at the time.

This does seem annoying, but does ghcup compile not provide a way of augmenting the cabal.project file and overriding the index-state, or am I mis-remembering?

I also think that in this particular case doing it all with bounds wouldn't have helped: since the GHC API has approximately no stability guarantees, our bounds would probably need to exclude ghc-lib-parser-9.8.5 since it might contain breaking changes. Of course, this could occur with a different non-reinstallable library where we just needed a new patch version of some other library to make it work, but we're getting into a smaller niche here.

So overall I'm not inclined to give up the fairly substantial benefits of pinning index-state in order to maybe sometimes let people build with a GHC we haven't tested yet?

[hasufell]

Sure. I can also purge index state in ghcup by default.

[michaelpj]

Sure. I can also purge index state in ghcup by default.

I think that will lead to more instances of users not being able to compile things but 🤷

[hasufell]

Sure. I can also purge index state in ghcup by default.

I think that will lead to more instances of users not being able to compile things but 🤷

I think that assessment is incorrect.

The main use case of ghcup compile hls has always been to build HLS for configurations that don't have bindists yet:

• new GHC versions (there's now 3 unsupported new GHC releases and one unsupported RC)... HLS releases have been severely lacking
• unsupported platforms
• ABI mismatches

The index state is in most of those scenarios a nuisance.

People use master to get things to compile that aren't properly supported. Otherwise they can compile against a release branch or a hackage release.

[Bodigrim]

I think the biggest benefit of index-state is for CI jobs, so that cache is not invalidated by each and every minor update and revision of dependencies. That said, things like "We have a new GHC that we don't officially support" should better be expressed as explicit version constraints on ghc and ghc-lib-parser dependencies rather than hidden by opaque timestamp.

[hasufell]

Yes, we have PVP for a reason. It's true that PVP doesn't shield you from all and every miscompilation. But I don't think "reproducible" is really a goal here... it's successful compilation.

• you can force index state in CI through a github actions env var
• have nightly builds without index state as an early warning system
• set index state in release branches/tags

Edit: And if you really want to harden against PVP issues... use qualified/explicit imports.