Allow updates without recompilation

[treeowl]

I can't stand having to recompile haskell-ci, and likely various dependencies thereof, just to bump GHC versions in the generated files. Couldn't this be handled in some more graceful way?

[phadej]

The main requirement I have is that version info embedded into generated file is reflecting the needed bits.

I guess we could have a configuration file available on the web, but it has to be versioned too.

That said, so far often enough the generation itself had been changing. So maybe it's still easier to just hardcode the configs, but maybe rather provide a prebuilt binaries (for linux it's easy enough).

[treeowl]

A versioned config file sounds like an excellent idea, and making binaries available wouldn't hurt. Does generation need to change every time, or does that just happen to occur? That is, could program versions be supported for a good while with new config files? It would be good to eventually get a warning like "a new configuration is required to support X, but you'll need to upgrade to get it."

[phadej]

does that just happen to occur?

Well, yes: bugs are fixed and features are added.

The current approach is least maintenance for me, there's already an overhead of making releases to Hackage which I'm not particularly happy about. It could be that if I do binary releases, there won't be Hackage releases anymore.

[nomeata]

Could haskell-ci use the ghcup information at least to find out which GHC versions exist? And maybe optimistically treat any GHC newer than what’s hardcoded in haskell-ci as behaving like the latest known version? This would probably allow us to support new GHC releases faster in many cases.

[phadej]

Could haskell-ci use the ghcup information at least to find out which GHC versions exist?

No. The delay between haskell-ci supporting newer GHC have been less than a day. I also value that haskell-ci version (included in generated file) determines exactly what is generated, not relying on any external information.

---

An example:

ghcup's metadata for GHC-9.8 alphas was also messed up:

│✗   GHC   9.8.1          latest,base-4.19.0.0                2023-10-09
│✗   GHC   9.8.1-alpha1   prerelease,base-4.19.0.0            2023-07-28
│✓   GHC   9.8.0.20230929 latest-prerelease,base-4.19.0.0     2023-09-29
│✗   GHC   9.8.0.20230919 prerelease,base-4.19.0.0            2023-09-19
│✗   GHC   9.8.0.20230822 prerelease,base-4.19.0.0            2023-08-23
│✗   GHC   9.8.0.20230809 prerelease,base-4.19.0.0            2023-08-09

I had to make code changes to support alpha1. And I'm 100% sure that such human mistakes or unexpected changes will happen in the future too.

So, again, No. I don't want to rely on any external source not explicitly made to be consumed by third parties (i.e. have good specification which can be relied upon), and even then I learned to be skeptical.

[nomeata]

Fair enough. When you say supported for new GHC releases, do you mean master or a released tag?

[phadej]

I mean master.

I make release only at "everything seems to be ok" points. E.g. now there is no cabal-install which doesn't warn about GHC-9.8 (i.e. we are waiting for cabal-install-3.10.2.0 haskell/ghcup-metadata#127)

In other words, currently there isn't complete setup to work with GHC-9.8. Using cabal-install-3.10.1.0 seems to work, but it does warn:

Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0 supports
'ghc' version < 9.8): /opt/ghc/bin/ghc-9.8.1 is version 9.8.1

That's another point, haskell-ci is not really the bottleneck in rolling out support for newer GHC versions.

[nomeata]

Ok, thanks for the clarification! I hope I didn't sound ungrateful, I'm just trying to understand at which point as a library author I can be expected to support a new GHC release.

[phadej]

I'm just trying to understand at which point as a library author I can be expected to support a new GHC release.

If you are willing to be on the bleeding edge, than you need to build master, and accept other small wrinkles in the experience. I watch ghcup-metadata repository, so usually make updates within a day.

Otherwise, if you don't want to on the bleeding edge (e.g. you want use haskell-ci from Hackage), then you'll need do wait longer. I will eventually make a stable release at some point, but trying to do it quickly is not a priority. E.g. I may take my time to implement or tweak some features.

This time it will probably happen sooner, as there haven't been any massive development after latest stable release. (Only one breaking change, IIRC, and one which shouldn't affect users of release GHCs).