[chore] adjust readme to save users some hours

[MangoIV]

Fixes #26

[Bodigrim]

Could we express it in a way, which would require less updates in the future, when Stackage moves to newer versions of GHC?

[MangoIV]

I'm not sure what the update policy is. Since this mentions 9.10 anyway, I thought it's fine if this is just changed whenever the stackage is (rarely) updated.

[MangoIV]

Do you have any suggestions, perhaps? I'm not a maintainer so I don't wanna suggest anything that is hard to maintain.

[Bodigrim]

First of all, while stackageSnapshot = "nightly-2025-05-23" is hardcoded, I'm happy to accept a PR bumping it to the latest Stackage Nightly or implementing a more flexible scheme. The reason it is hardcoded, I believe, is that there used to be an issue with Stackage server with not all snapshot endpoints available in JSON format. Perhaps it has been fixed and we can just pick up the latest?..

Secondly, you can download any cabal.config you like (say, https://www.stackage.org/nightly-2025-11-12/cabal.config) and use it by specifiying --snapshot-path. And if boot libraries have been upgraded in the GHC source tree, you can edit them manually in the downloaded cabal.config.

[tbidne]

You're right; the minor version issue is extremely annoying. While upgrading this to 9.12.2 on my local branch, I added boot packages to excluded_pkgs.json, which should at least alleviate that problem (this probably needs to be done even when they become re-installable, as ghc is in the build plan).

Separately, changing stackageSnapshot = "nightly" and removing generated/cabal.project's index-state sounds plausible, though there are some nuances.

• In general, a new major snapshot brings a bunch of new packages that need to be excluded -- e.g. they contain system deps or are executables -- so at some point nightly will not be buildable here, until a PR is made to add such packages to excluded_pkgs.json. At the present, this type of error would likely not be caught by CI, since the list of packages built by CI is necessarily very short.

  We could add a test that in fact runs clc-stackage with everything and --dry-run. This is quite fast and would detect both the errors above, since they are solver errors. It wouldn't detect actual build errors (hopefully stackage itself would?), but maybe it's good enough.

• You'd still need to signal to users which ghc to use. I guess the readme could say "look at ci.yaml", or whichever ghc the latest nightly snapshot corresponds to.

• I'm not sure what stackage's policy is, but lts might provide a more stable hardcoded path e.g. https://www.stackage.org/lts or https://www.stackage.org/lts-24 (resolves to the latest 9.10). The latter would require someone to bump it every so often, but you'd probably want to do that anyway for ci.yaml.