Can stack utilize ghcup?

[hasufell]

Stack uses the following metadata to install GHC: https://github.com/commercialhaskell/stackage-content/blob/master/stack/stack-setup-2.yaml

It uses different "keys" than ghcup. Instead of going via distro/distroversion, it goes via things like linux32-gmp4-nopie, examining some system libraries (gmp, ncurses, tinfo).

Further, it installs GHC into some private location under ~/.stack/programs/x86_64-linux/ or so.

---

So, I'm not entirely sure what would stack need from ghcup to drop maintaining its GHC installation bits completely.

GHCup could start to:

1. support the stack metadata as a source for installation

Stack developers would need to decide:

1. is this even worth it?
2. what exactly would they need from GHCup to make this more feasible in terms of behavior/features
3. what API would be expected? Interface with GHCup as a library or as a command line tool? If the former, we'd likely need to do some designing.

@mpilgrem just putting this out here for discussion

[hasufell]

@mpilgrem any interest to discuss this?

[mpilgrem]

@hasufell, yes, indeed, but my attention has been elsewhere recently.

There was a related discussion in the #stack-collaborators channel of the Haskell Foundation's Slack workspace recently - prompted, I think, by the Debian 10/11 glibc difficulties. The idea of a stack-setup-3.yaml was floated. I asked (in terms): 'If GHCup had 'solved' the problem of GHC installation for users of the many different Linux distributions that are out there, should Stack just follow GHCup's example?'. Stack 'adopting' GHCup (as opposed to just 'facilitating' GHCup, thanks to your additions to Stack) would be the most direct way for Stack to follow GHCup's example.

The UK's National Health Service says of the human appendix: 'Nobody knows exactly what it does, but removing it is not harmful.' I suspect that Stack's ability to manage GHC directly will, in time, become like the appendix. The popularity of Visual Studio Code and its (excellent) Haskell extension will see to that. GHCup providing a TUI for Windows users will accelerate the evolution. However - and perhaps this is just sentiment on my part - I would be reluctant to amputate the appendix before a serious case of appendicitis. If I were looking for rational reasons, I think I would point to the importancy of redundancy in the engineering of critical systems; and not disturbing CI scripts that assume that Stack will manage GHC and manage it in certain locations (I assume that CI scripts adapt to change less nimbly than people who use tools).

[hasufell]

I think my proposal is not entirely clear.

What I'm suggesting is that nothing of stacks behavior changes at all, but that the implementation of GHC installation moves completely to GHCup... with all the logic that stack needs.

Hence the idea to start supporting stack style GHC metadata.

[mpilgrem]

@hasufell, I think my lack of comprehension is because I do not know quite what it means for 'GHCup to start supporting Stack-style metadata'.

This is my basic understanding of what Stack currently does:

A user asks of Stack: "Use the binary distribution of (say) GHC 9.2.5 that is 'right for me'."

Stack has to work out what architecture/system (in a detailed sense) the user is actually on, work out what is the best available binary distribution of GHC 9.2.5 for that architecture/system, fetch it, and put it somewhere where Stack can find it. It tries to do all that 'behind the scenes', but a sophisticated Stack user can interfere/override/configure, if the user wants to. In recent years, 'available' has, in practice, meant 'made available by the GHC developers' but it can mean 'available anywhere'. For Windows users, or Apple machines (Intel-based or Apple silicon), that is currently relatively simple. For users of Linux distributions, it can be complicated. There is also FreeBSD, which I know very little about. The heavy lifting is done by Stack's stack setup command. At the heart of the process is (1) the detection and 'classfication' of platforms (which is complicated for Linux-based platforms); and (2) a mapping from (a) a platform-as-classified-for-the-purpose to (b) the location of a binary distribution of GHC (the default stack-setup-2.yaml setup-info dictionary).

If a 'Stack 3.0' could depend on a dependable open source library (or, equivalently, a dependable command line tool) to do some or all of that, I can't see any barrier to that change. However, users of Stack < 3.0 would need to be supported in the old way, until the number of such users dwindled.