Define GHC versions via updatable configuration

[lierdakil]

Hard-coding GHC versions seems like a recepie for always playing catch-up with GHC patch-releases. I think ghcup chose a better approach: it uses a YAML config file, which it can pull from repo. Perhaps something similar could be arranged here?

[chshersh]

ghcup and Summoner are different in this regard because ghcup provides artefacts, while Summoner also contains logic to derive various outputs from the GHC versions:

• base version
• Stackage snapshot version
• Specific hacks to make CI work if something becomes broken
• New GHC warnings and flags
• Cabal version depending on GHC version

So, as you can see, it's not really possible or desirable to get this information automatically. Moreover, even minor version changes of GHC can result in broken CI pipelines on various platforms (Travis, AppVeyor, GitHub Actions, Windows, macOS), so each new Summoner release not only updates versions but also checks that the CI is still working.

Moreover, it often happens that the CI infrastructure is not updated automatically once the new GHC version comes out, so it doesn't make much sense to configure GHC versions automatically in Summoner via YAML or something similar, because the generated project can become broken after that.

Updating the Summoner code to support new GHC versions is not that difficult anyway, but at least after the manual update, we have guarantees that the new version works. We value smooth UX more than having to do less work.

[lierdakil]

base version Stackage snapshot version Specific hacks to make CI work if something becomes broken New GHC warnings and flags Cabal version depending on GHC version

... all of which can be easily declared in a YAML file. Well, maybe except CI hacks. The rest isn't "logic", it's just "data".

Besides, you could at the very least use it to quickly push out information about GHC's patch-releases, which wouldn't require much additional info.

Reason I'm bringing this up: official release currently doesn't know about GHC 8.10. Master branch doesn't know about GHC 8.10.4. I really would want to use summoner and recommend it to my students, but the lack of support for recent releases makes it rather hard.

[chshersh]

@lierdakil We work on Summoner in our free time, and our work depends on availability, so we don't have any deadlines or release schedules. But we do have milestones to plan what we want to include in the next release. We prefer to focus on multiple features and produce a new release with several features because we don't have the capacity to do often releases.

The implementation of the config wouldn't solve your problem because the config still needs to be updated. Somebody still needs to write new information in that configuration. As I mentioned before, it's not that difficult to change Summoner to support new GHC versions, so I don't see how having a configuration will solve your problem. If you imply, that users need to update their own local configuration to get the newer GHC version then I don't think it's a good idea for the reasons I mentioned above, in addition to higher maintenance overhead.

[lierdakil]

We work on Summoner in our free time

As most of us do. To be clear, I'm not demanding anything -- I'm just trying to suggest a (hopefully) reasonable workflow optimization that I'd be happy to make a PR for if that's something you'd be interested in.

If you imply, that users need to update their own local configuration

No, I didn't imply that. Although that could be useful in some cases, I don't think the overhead is justified. This can be discussed separately if need be.

I don't see how having a configuration will solve your problem

If the configuration is (semi-)automatically pulled from the main branch -- akin to how ghcup does that -- this would if not solve the problem entirely, at least mitigate it to a reasonable degree.

Somebody still needs to write new information in that configuration.

Of course the config will need to be updated. My point is if the config is automagically pulled by Summoner, this will make it so that users can use newer GHC without necessarily waiting for the next Summoner release -- which, as you say, can take arbitrary time. Sorry if this wasn't clear.

it's not that difficult to change Summoner to support new GHC versions

Granted, but that changed version now needs to be released, built and distributed. Unlike with my proposal, where the user only needs a working Internet connection and maybe to run a command like summon update. Or, if nobody updated the config yet, the user (for instance, me) might submit a PR against the config, which, when merged, can be used immediately.

For instance, my issue with GHC 8.10.4 not being recognized by Summoner could be easily fixed by submitting a PR here instead of the whole complicated song and dance with forking, patching, building and distributing. Or indeed having this conversation.

Besides, arguably, Summoner is primarily useful for beginners. I can patch it, but I can manage with just cabal init if I have to. But you can't reasonably expect beginners to go patch the sources and basically roll their own.

[lierdakil]

To put my time where my mouth is, here is a quick-and-dirty prototype: https://github.com/lierdakil/summoner/commit/54d8efb64c4246720dcfe5d81f10d7a3e1133e70. Uses unsafe IO to read from cache, but it's a pretty safe use of unsafe IO.

It's possible to catch errors in the embedded config file at compile-time with TH. I didn't really want to fiddle with TH at this time, hence file-embed.