Feature parity with Stack

[NorfairKing]

I would love to switch away from stack for development, but there are some real and important things missing to do so.
In this issue I'd like to list those with checkboxes, in case feature-parity with stack is something the cabal team would want to achieve:

• cabal test all --no-rerun-tests: Don't rerun test suites that have already passed.
• cabal test all --coverage: Multi-package code coverage reports
• cabal build all --file-watch: File watching. This is arguably not cabal's responsibility because you can do something close-enough with feedback for example, but cabal is haskell-build-process-aware and could do better than feedback can.
• Automatically executing hpack when necessary.
• --pedantic
• Dependency graph

Not available and not desirable IMO:

• GHC installation

---

UPD More ideas from the discussion below:

• Loading multiple packages in cabal repl a la stack repl.
• Better support for snapshots (details: Feature parity with Stack #8605 (comment))
• Docker integration (see stack documentation)

[ulysses4ever]

Would help to have links to respective stack documentation sections.

[NorfairKing]

@ulysses4ever Good idea, I added some links.

[tfausak]

Although I have switched from Stack to Cabal for development, I agree with this list and would like to see these things implemented. I think there are existing issues for some of them:

cabal build all --file-watch

• cabal watch command #5252

Automatically executing hpack

• Module listing discovery (wildcard glob) #5343 (related issue suggesting new feature that hpack currently has)
• Migrate from the .cabal format to a widely supported format #7548 (related issue suggesting a new file format entirely)

[fgaz]

Automatically executing hpack when necessary

• shell hooks for augmenting how cabal-install does various actions? #7394

[chrisdone-artificial]

Regarding feature parity

• Loading multiple packages in cabal repl a la stack repl would also be nice.

• A thing that I get mileage out of with Stack is (1) specifying a Stackage snapshot in one line (rather than a big lock file), and (2) the fact that I can then cherry-pick and pin individual package versions down to the SHA hash. This experience is quite different to the big lock file specifying all dep versions, and the hash pinning allows you to not trust the package server.

• Personally, I think GHC management is a big deal. But it's worth noting that the Haskell community is split into those who use Nix and those who don't. So it's common for a lot of Cabal-using devs to defer certain features (such as package pinning or GHC management) to their Nix configuration, similar to using entr/watchexec instead of --file-watch, but that leaves the other half of the community preferring to stick with Stack!

(Although maybe like @tfausak some people just ignore the few missing features and use Cabal.)

Regarding docs

I'd eagerly read some kind of "cabal for stack enthusiasts" article which explains how to achieve all the things you're used to with stack from a proper stack user's perspective (not a cabal user who's vaguely aware of what stack can do or used it a little bit).

Contributing

I'm afraid I can't contribute any work towards this. I've done my time on Haskell tooling. 😂 Around 2015, I wrote the first commit on Stack and shaped some of its direction, alongside Michael Snoyman, Michael Sloan, Emanuel Borsboom. Tooling is Hard, especially Haskell as it's a moving target. The best outcome would be that the community converges again on one build tool. But it's taken years to get to this point and may take some more years yet!

[fgaz]

Loading multiple packages in cabal repl

• Multiple Home Units support #8238

specifying a Stackage snapshot in one line

• RFC: Cabal support for LTS Snapshots #7556
• [Feature] remote freeze files #6528
• Document Stackage use with remote project config #8083

the fact that I can then cherry-pick and pin individual package versions

• Rest of RFC: Cabal support for LTS Snapshots #7556 (package collection algebra)

Personally, I think GHC management is a big deal

• shell hooks for augmenting how cabal-install does various actions? #7394

[xplat]

I think both automatic hpack execution and auto-expanding Stackage snapshot names to lockfiles are best done via hooks, since they break off nicely into discrete tasks that already have well-known public interfaces. (I admit for hpack specifically I am biased in that I don't like hpack's design decisions and don't want Cabal to endorse it.)

[gbaz]

I am curious how cabal test all --no-rerun-tests would work specifically? It sounds intriguing and a ticket on it would be welcome, especially coupled with some explanation of the semantics of the existing stack feature.

A ticket for multi-package code coverage would also be welcome.

[JakobBruenker]

Not available and not desirable IMO:

• GHC installation

I think I agree, but I do think it would be nice if cabal could somehow select among the installed GHC versions for a particular project, perhaps by interfacing with ghcup.

[merijn]

I think I agree, but I do think it would be nice if cabal could somehow select among the installed GHC versions for a particular project, perhaps by interfacing with ghcup.

GHC by default includes executables with complete version numbers, cabal supports -w to specify a compiler to use, and this can be stored in cabal.project/cabal.project.local files.

Personally, I have a setup where my "default" ghc is first in path, followed by all other installs. This causes ghc to refer to the first (i.e. my default) ghc executable in my path, while version tagged GHCs are found later on path. This way simply writing cabal build -w ghc-8.10.7 will use the relevant GHC and this can be stored in aforementioned config files too.

All that would be needed to point a project to a specific GHC installed via ghcup would be: cabal configure -w path/to/ghc-version and from then on cabal build will automatically use that one.

[JakobBruenker]

@merijn that is good to know, thank you

[NorfairKing]

I am curious how cabal test all --no-rerun-tests would work specifically? It sounds intriguing and a ticket on it would be welcome, especially coupled with some explanation of the semantics of the existing stack feature.

@gbaz Stack keeps track of which test suites have been run since their dependencies have last changed and whether the run was successful (exit code 0, I guess). Then it doesn't rerun the test suite if it's already succeeded and the dependencies haven't changed.