'ghcup satisfy' command

[hasufell]

In GitLab by @maerwald on Dec 13, 2020, 01:02

This command could install the correct GHC version in a cabal project based on various metrics:

1. look for a stack.yaml and pull the GHC version from the resolver/config
2. look for cabal.project for pinned compiler
3. interpret foo.cabal and figure out the maximum base constraint (how?) and then use a base-ghc mapping to install the correct GHC

Third option seems like the gold standard, but in order to find the highest allowed base version, we need to do an actual resolution I believe...

---

Edit: plan.json we cannot use, because that requires a cabal run with ghc already installed I believe.

[hasufell]

In GitLab by @maerwald on Dec 13, 2020, 02:58

Relevant: haskell/cabal#6885

Discussion on IRC

19:55 <maerwald> phadej: do you have an idea on how to get the highest satisfiable base version of a cabal project without invoking cabal-the-binary?
19:55 <phadej> without running solvers? no.
19:56 <maerwald> can you run cabal without a ghc installed maybe? That would be a workaround, then read plan.json
19:57 <phadej> there is a plan for being able to do that, but it's a light year away
19:57 <phadej> https://github.com/haskell/cabal/issues/6885

[hasufell]

In GitLab by @Franciman on Dec 16, 2020, 05:15

Hi,

Edit: plan.json we cannot use, because that requires a cabal run with ghc already installed I believe.

For doing this vabal used a trick, I am not sure this is very accurate, or if it is a viable option,
basically, cabal for calculating the plan used to (not sure this is the case anymore) call ghc for the capabilities of the compiler and ghc-pkg to query about packages registered in the db, now the important packages are the boot packages that are strongly tied to the compiler version, so I created a script that substitues ghc and ghc-pkg and prints the relevant info. They are contained here:
https://github.com/vabal/vabal-ghc-metadata/blob/master/fake-ghc.tar
I'll attach the two files for ghc.8.6.4 for fast reference:
ghc
ghc-pkg

In this way you can run cabal build --dry-run using these scripts passed as -w option (the dry-run option makes cabal just run the configuration without writing anything to the disk, whilst configure would write a cabal.project.local file)
and thus you can try the ghc versions you want and actually see if they work.

Regarding

interpret foo.cabal and figure out the maximum base constraint (how?) and then use a base-ghc mapping to install the correct GHC

Can I suggest you also consider the Cabal library constraints in the setup-depends stanza?
Because cabal adds a lower bound on the Cabal version allowed based on the ghc version:
https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/ProjectPlanning.hs#L1117
therefore in finding what ghc to use, one must also consider the Cabal constraints, otherwise one could end up with a GHC too new that won't support the given Cabal.
But this was a problem only for the Cabal dependency in the setup-depends stanza, last time I checked, not sure this is still what is happening.

Finally if it is helpful here you can find vabal's code for base + Cabal resolution:
https://github.com/vabal/vabal/tree/master/vabal-lib

For the fake ghc cabal planning you can find the code here:
https://github.com/vabal/vabal/blob/07aef09a3fc8ef2fd282f3027e90aec93ecf73d7/vabal/src/VabalMain.hs#L144

Let me know if I can help in some way.

[hasufell]

In GitLab by @maerwald on Jun 1, 2021, 19:10

Let me know if I can help in some way.

If you want to have a shot at an implementation, I'd be all ears...

[hasufell]

In GitLab by @fgaz on Nov 5, 2021, 16:46

The third option could just pick the latest or recommended ghc from tested-with if present