ghcup but for individual packages

[chreekat]

What if ghcup had a mechanism to inspect a cabal file (or project file), determine which version of GHC is needed to build it (based on base constraints or something), and install that version if necessary?

I suppose this could also be a cabal feature (cabal setup -> calls ghcup if necessary), but as a ghcup feature it would be a single entrypoint for any Haskell project.

For the language-server use case, I guess ghcup should already be installed as part of enabling Haskell, and thus some version of cabal is also available. Thus it doesn't matter where this feature is implemented in that case.

For the power user use case (i.e. any use that involves opening a terminal), curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh && cabal setup is probably still short enough for any maintainer to recommend to contributors, so maybe cabal is the right place for this, since cabal will have a better chance of figuring out which version of ghc is needed.

The downside of making it a cabal feature, of course, is the complicated chain of each tool being able to download and install the other...

[hasufell]

What if ghcup had a mechanism to inspect a cabal file (or project file), determine which version of GHC is needed to build it (based on base constraints or something), and install that version if necessary?

That was basically already discussed here as ghcup satisfy: #109

The related cabal ticket is haskell/cabal#6885

However, I'm not sure this is actually a feature that should live in GHCup.

For installing GHC automatically, we should use cabal hooks: haskell/cabal#7394
But that will only select GHC based on e.g. cabal.project. But it won't do any resolution to figure out which GHC version (or rather base version) would produce a valid build plan.

GHCup is about installing toolchain. Trying to figure out what toolchain might actually work seems like a separate concern that neither fits cabal, nor GHCup, but I'm not sure. And this is a fundamentally fuzzy feature. The build might still fail in the end.

[chreekat]

I agree this is a duplicate of #109 (so I'll close it).

Plus I think I agree that GHCup isn't the right place for such a feature.

[hasufell]

I'm not completely opposed to having it in GHCup, but in my opinion, there are two different concerns here:

• installing the project GHC (the one cabal will see... this depends on cabal.project or the ghc binary in PATH)
• figuring out the latest versions of boot libraries that would produce a valid build plan

For the first we can use the already mentioned cabal hooks (if they ever get completed).

For the latter, this might be a use case for @phadej's cabal-extras: https://github.com/phadej/cabal-extras
The downside is it would require another binary. But is that use case really that common?