Add project-plan command

[phadej]

You can force project planning by using cabal build --dry. That command is however requires that you in fact have build environment set up. The project-plan should be able to take all required information as separate input (compiler information, installed package info db, pkgconfig db, ...).

project-plan would both useful for system independent testing (simulating various scenarios, where setting up environment is just too tricky for CI), and we can use it to produce plans for cabal's new bootstrap (#6700).

cc @angerman @bgamari

I suspect that this will require some non-trivial changes inside cabal-install, but I do think they will be for better, making implicits explicit.

[hasufell]

Another use case might be ghcup using this to figure out a suitable GHC version for a project: https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/99

[jneira]

• for hie-bios to get as well the ghc of a project and gives it to tooling using the lib (like haskell-language-server)
• it think this should be part of cabal info (Add status command to cabal #7500)

[andreabedini]

Late to the party but it turns out I had a go a this. I requires moving few things around but IIRC no roadblocks. I had a version of ProjectPlanning.hs that takes compiler, platform and arch as parameters.

The only issue was with pkg-config, as we cannot know in advance which packages might be relevant for the plan. Perhaps we could overapproximate the set of relevant pkgconfig entries and report that to the user? I am not sure how this would work.

Let me know if there's still interest.

[phadej]

@andreabedini

relevant pkgconfig entries and report that to the user?

cabal-installs solver takes the whole pkgconfig database as the input.

---

EDIT: Note that my original request was asking to take the whole global package db as an input as well. E.g. on linux you don't have Win32, but on Windows you do (but don't have unix). Nor you cannot really predict their versions either.

[andreabedini]

cabal-installs solver takes the whole pkgconfig database as the input.

That might be the only solution.

Note that my original request was asking to take the whole global package db as an input as well.

Good point.

Now I remember another thing that wasn't entirely trivial: cabal-install wants to know a lot about the compiler (it calls --info). I think it mostly end up using the list of supported extensions and languages; but I am not sure to what purpose.

[phadej]

but I am not sure to what purpose.

If you say

other-extensions: SomethingFancy

and the compiler doesn't know it, solver will take that into account. (E.g. say you want QuantifiedConstraints, or OverloadedRecordDot...)

i.e. a capability based compiler support. (It would been better if extensions didn't change, but that works well for things like QuantifiedConstraints or TypeApplications, which are more-or-less perfect in the first GHC they were added).

[andreabedini]

I have made a poc https://github.com/andreabedini/cabal-solver-plan
Note that this is only the (per-package) solver plan and not the (per-component) elaborated plan.