[ANN] First release candidate for stack-2.9.1

You can download binaries for this pre-release from: Release v2.9.0.1 (release candidate) · commercialhaskell/stack · GitHub.

Please test it and let us know at the Stack repository if you run into any trouble. If all goes well, we hope to release the final version in a couple of weeks.

Changes since v2.7.5:

Behavior changes:

  • stack build --coverage will generate a unified coverage report, even if
    there is only one *.tix file, in case a package has tested the library of
    another package that has not tested its own library. See
  • stack --verbose no longer includes the lengthy raw snapshot layer (rsl) in
    the debug output by default. The new stack --[no-]rsl-in-log flag enables or
    disables the inclusion of the rsl in the debug output.

Other enhancements:

  • Bump to Hpack 0.35.0.
  • On Windows, the installer now sets DisplayVersion in the registry, enabling
    tools like winget to properly read the version number.
  • Adds flag --script-no-run-compile (disabled by default) that uses the
    --no-run option with stack script (and forces the --compile option).
    This enables a command like stack --script-no-run-compile Script.hs to
    behave like stack script <arguments> --no-run --compile -- Script.hs but
    without having to list all the <arguments> in the Stack interpreter options
    comment in Script.hs on the command line. That may help test that scripts
    compile in CI (continuous integration). See
  • Fuller help is provided at the command line if a subcommand is missing (for
    example, stack ls now yields the equivalent of stack ls --help ). See
  • Add build option --cabal-verbosity=VERBOSITY to specify the Cabal verbosity
    level (the option accepts Cabal’s numerical and extended syntax).
    See #1369
  • Add the possibility of a sh script to customise fully GHC installation. See
  • tools subcommand added to stack ls , to list stack’s installed tools.
  • stack uninstall shows how to uninstall Stack.
  • --ghc-variant accepts int-native as a variant.

Bug fixes:

  • Fix stack clean --full , so that the files to be deleted are not in use. See
  • Fix an inconsistency in the pretty formatting of the output of
    stack build --coverage
  • Fix repeated warning about missing parameters when using stack new
  • Include pantry-0.5.6 : Remove operational and mirror keys from bootstrap key
    set #53
  • Pass any CPP options specified via cpp-options: in the Cabal file to GHCi
    using GHC’s -optP flag. See
  • On Unix-like operating systems, respect the with-gcc option when installing
    GHC. See #5609
  • Fixed logic in get_isa() in get-stack.sh to exclude systems that don’t
    have x86 in their uname -m output. See
  • Fixed output of stack ls snapshots local on Windows, to behave like that on
    Unix-like operating systems.
  • Fix non-deterministic test failures when executing a test suite for a
    multi-project repository with parallelism enabled. See

:partying_face: :dancer:

GHCup will then add an option in the bootstrap installer script to install a shell hook for stack that defers GHC installation to GHCup.


The change log above doesn’t seem to mention the GHC versions that stack-2.9.1 is compatible with. Is this release planned to be able to run GHC 9.4 without a warning? Currently with GHC 9.2, I see

Stack has not been tested with GHC versions above 9.0, and using 9.2.4, this may fail
Stack has not been tested with Cabal versions above 3.4, but version was found, this may fail


We have bumped those warning messages to GHC > 9.4 and Cabal > 3.8. I can’t rule out that there are some features of Cabal- that Stack 2.9.1 does not support. I know that some Cabal features that had been ‘experimental’ ceased to be experimental with Cabal- One of my personal ‘to dos’ is (a) to understand those features and (b) to understand if Stack needs to change to accommodate them.


Please contact @sclv and @Mikolaj and possibly schedule a meeting. There should be more coordination and communication with cabal devs, because stack is a major consumer of Cabal-the-library.

1 Like

@mpilgrem: Indeed, we are at your service. I think the major ‘experimental’ feature turned mainstream in cabal has been multiple public libraries per single package. @fgaz is the expert on that functionality and @sclv manages Hackage overhaul necessary to support it.