cabal setup

[chreekat]

Imagine a command that ensures the toolchain is set up for a particular project.

I can imagine hacky things that rely on ghcup, which would maybe be ok for prototyping but bad overall for experience.

See haskell/ghcup-hs#835 for the original idea. I'm opening a ticket here as well because my ghcup idea morphed into a cabal idea.

[ulysses4ever]

When you say "toolchain is set up" I immediately think about GHCup. Cabal, on the other hand, was never meant to provision something other than cabal packages, I think. If you want to extract some info from Cabal files and try to figure how to setup a toolchain, then it's a good case for using Cabal(-syntax) as a library.

I'd be curious to know how other ecosystems are doing in this matter. For one, Juila's package manager is in no way responsible for setting up the right Julia version. It can warn that a Manifest file (analog of freeze files in Cabal parlance) was created by another version of Julia and that the user may be better off with running the solver again.

Other possibly relevant thoughts can be found in #8605. (Esp. w.r.t. GHC installation.)

[andreabedini]

@chreekat I think this is space well worth exploring! If you allow me a drive-by consideration: I believe we should start making a clear separation of package- and project- related features.

Apologies for the wall of text; I have been thinking about this a lot 😂.

IMHO, cabal-install v2 has introduced project level functionality but failed to distinguish them from the previous package level ones; and (again IMHO) this has lead to some poor UX.

One example of this is cabal init, which is explicitly about creating a package and does not deal with project configuration. Since the with-compiler option makes sense only at a project level, the meaning of cabal init -w could be a bit surprising. You can see this confusion show up in #5700.

Another example, this time reversed, is cabal configure which configures a project and has nothing to do with packages. In some sense the configure command is already your (rudimental) setup.

Of course, we cannot afford breaking changes to the CLI interface, so this aboguity cannot be resolved immediately. Maybe we could start thinking about introducing cabal project subcommands?

[andreabedini]

The dotnet cli seems to make a clear distinction between packages, projects and tools.

https://learn.microsoft.com/en-us/dotnet/core/tools/