stack 2.15.1 → 2.15.3
raw patch · 44 files changed
+733/−455 lines, 44 filesdep ~pantry
Dependency ranges changed: pantry
Files
- CONTRIBUTING.md +14/−13
- ChangeLog.md +29/−17
- cabal.config +2/−2
- doc/CONTRIBUTING.md +14/−13
- doc/ChangeLog.md +29/−17
- doc/GUIDE.md +29/−27
- doc/azure_ci.md +10/−10
- doc/build_command.md +31/−32
- doc/build_overview.md +2/−2
- doc/config_command.md +11/−10
- doc/dev_containers.md +2/−2
- doc/faq.md +8/−9
- doc/ghc_command.md +6/−4
- doc/ghci.md +18/−0
- doc/global_flags.md +14/−7
- doc/glossary.md +4/−2
- doc/hpc_command.md +4/−4
- doc/ide_command.md +1/−1
- doc/init_command.md +11/−1
- doc/install_and_upgrade.md +80/−22
- doc/list_command.md +5/−5
- doc/lock_files.md +12/−12
- doc/ls_command.md +2/−2
- doc/new_command.md +5/−2
- doc/nix_integration.md +5/−4
- doc/nonstandard_project_init.md +2/−1
- doc/pantry.md +1/−1
- doc/path_command.md +4/−4
- doc/query_command.md +1/−1
- doc/runghc_command.md +6/−4
- doc/script_command.md +9/−9
- doc/scripts.md +10/−10
- doc/stack_yaml_vs_cabal_package_file.md +4/−4
- doc/unpack_command.md +2/−2
- doc/upgrade_command.md +13/−1
- doc/yaml_configuration.md +107/−76
- src/Stack/Build/ExecuteEnv.hs +0/−6
- src/Stack/Build/ExecutePackage.hs +15/−14
- src/Stack/Exec.hs +44/−8
- src/Stack/Options/ExecParser.hs +3/−2
- src/Stack/Options/PathParser.hs +9/−2
- src/Stack/Path.hs +149/−85
- stack.cabal +5/−5
- stack.yaml +1/−0
CONTRIBUTING.md view
@@ -285,21 +285,22 @@ Stack aims to depend on well-known packages. The specific versions on which it depends at any time are specified by `package.yaml` and `stack.yaml`. It does not aim to be compatible with more than one version of the `Cabal` package at -any time. At the time of writing (August 2023) the package versions are -primarily ones in Stackage snapshot LTS Haskell 21.8 (for GHC 9.4.5), together -with extra-deps to depend on the latest versions of `ansi-terminal`, `crypton` -(instead of `cryptonite`), `hpack`, `pantry` and `tar-conduit`. +any time. At the time of writing (February 2024) the package versions are +primarily ones in Stackage snapshot LTS Haskell 22.7 (for GHC 9.6.4), together +with extra-deps to depend on the latest version of `pantry` and `process`. A Stack executable makes use of Cabal (the library) through a small 'Setup' executable that it compiles from Haskell source code. The executable compiles that code with a dependency on the version of Cabal that ships with the -specified GHC compiler. Each release of Stack will aim to support all versions -of GHC and the Cabal package in Stackage snapshots published within seven years -of the release. For example, snapshot LTS Haskell 8.0, published on -12 February 2017, was the first LTS Haskell snapshot to provide GHC 8.0.2 which -comes with `base-4.9.1.0` and `Cabal-1.24.2.0`. Until, at least, -13 February 2024, Stack releases would aim to support the immediate -predecessor, GHC 8.0.1 and `base-4.9.0.0`, `Cabal-1.24.0.0` and Haddock 2.17.2. +specified GHC compiler. Each release of Stack will normally aim to support all +versions of GHC and the Cabal package in Stackage snapshots published within +seven years of the release. For example, snapshot LTS Haskell 10.0, published on +19 December 2017, was the first LTS Haskell snapshot to provide GHC 8.2.2 which +comes with `base-4.10.1.0` and `Cabal-2.0.1.1`. Normally, until, at least, +19 December 2024, Stack releases would aim to support the immediate +predecessor, GHC 8.0.2 and `base-4.9.1.0`, `Cabal-1.24.2.0` and Haddock 2.17.4. +However, the next version of Stack will drop support for versions of Cabal +before 2.2. `Cabal-2.2.0.0` was released with GHC 8.4.1 on 8 March 2018. When a version of the Stack executable actually ceases to support a version of GHC and `Cabal`, that should be recorded in Stack's @@ -548,8 +549,8 @@ `--pedantic` flag. The `unit-tests` job runs on a matrix of operating systems and Stack -project-level YAML configuration files (`stack.yaml`). It builds and tests Stack -with the following flags: `--haddock --no-haddock-deps`. +project-level YAML configuration files (`stack.yaml`, by default). It builds and +tests Stack with the following flags: `--haddock --no-haddock-deps`. Its approach to creating a cache depends on the operating system. Its 'Cache dependencies on Unix-like OS' step caches the Stack root on Unix-like operating
ChangeLog.md view
@@ -1,19 +1,30 @@ # Changelog -## Unreleased changes +## v2.15.3 - 2024-03-07 Release notes: -**Changes since v2.15.1:** +* With one exception, this release fixes bugs. -Major changes: +**Changes since v2.15.1:** Behavior changes: -Other enhancements: +* `stack path --global-config`, `--programs`, and `--local-bin` no longer set + up Stack's environment. Bug fixes: +* Due to a bug, Stack 2.15.1 did not support versions of GHC before 8.2. Stack + now supports GHC versions from 8.0. +* `--haddock-for-hackage` does not ignore `--haddock-arguments`. +* On Windows, package locations that are Git repositories with submodules now + work as intended. +* The `ghc`, `runghc` and `runhaskell` commands accept `--package` values that + are a list of package names or package identifiers separated by spaces and, in + the case of package identifiers, in the same way as if they were specified as + targets to `stack build`. + ## v2.15.1 - 2024-02-09 Release notes: @@ -68,7 +79,7 @@ `1.24.0.0`. * Experimental: Add flag `--haddock-for-hackage` to Stack's `build` command (including the `haddock` synonym for `build --haddock`) to enable building - local packages with flags to generate Haddock documentation, and an archive + project packages with flags to generate Haddock documentation, and an archive file, suitable for upload to Hackage. The form of the Haddock documentation generated for other packages is unaffected. * Experimental: Add flag `--documentation` (`-d` for short) to Stack's `upload` @@ -89,7 +100,7 @@ key is introduced, to allow the notification to be muted if unwanted. * Add option `--filter <item>` to Stack's `ls dependencies text` command to filter out an item from the results, if present. The item can be `$locals` for - all local packages. + all project packages. * Add option `--snapshot` as synonym for `--resolver`. * Add the `config set snapshot` command, corresponding to the `config set resolver` command. @@ -222,8 +233,9 @@ `c2hs`, `cpphs`, `gcc`, `greencard`, `happy`, `hsc2hs`, `hscolour`, `ld`, `pkg-config`, `strip` and `tar`. If Cabal uses the program during the configuration step, the argument is passed to it. -* By default all `--PROG-option` options are applied to all local packages. This - behaviour can be changed with new configuration option `apply-prog-options`. +* By default all `--PROG-option` options are applied to all project packages. + This behaviour can be changed with new configuration option + `apply-prog-options`. * Add flag `--[no-]use-root` to `stack script` (default disabled). Used with `--compile` or `--optimize`, when enabled all compilation outputs (including the executable) are written to a script-specific location in the `scripts` @@ -243,8 +255,8 @@ * `stack build` with `--file-watch` or `--file-watch-poll` outputs 'pretty' error messages, as intended. See [#5978](https://github.com/commercialhaskell/stack/issues/5978). -* `stack build` unregisters any local packages for the sub libraries of a local - package that is to be unregistered. See +* `stack build` unregisters any project packages for the sub libraries of a + project package that is to be unregistered. See [#6046](https://github.com/commercialhaskell/stack/issues/6046). * The warning that sublibrary dependency is not supported is no longer triggered by internal libraries. @@ -254,7 +266,7 @@ Hackage-only release of the `stack` package: * Supports building against snapshot Stackage LTS Haskell 21.0 (GHC 9.4.5), - without extra deps. + without extra-deps. * Supports build with `persistent-2.14.5.0`, using CPP directives. * Supports build with `unix-compat-0.7`, by removing reliance on the module `System.PosixCompat.User` removed in that package. @@ -731,7 +743,7 @@ affect the Stackage Curator use case, but there is now an additional message letting the user know when a previously-failed test case is being rerun. -* Move configure information for local packages back to .stack-work to improve +* Move configure information for project packages back to .stack-work to improve caching. See [#4893](https://github.com/commercialhaskell/stack/issues/4893). @@ -917,7 +929,7 @@ * Support MX Linux in get-stack.sh. Fixes [#4769](https://github.com/commercialhaskell/stack/issues/4769). -* Defer loading up of files for local packages. This allows us to get +* Defer loading up of files for project packages. This allows us to get plan construction errors much faster, and avoid some unnecessary work when only building a subset of packages. This is especially useful for the curator use case. @@ -1625,7 +1637,7 @@ * `stack script` can now handle relative paths to source files. See [#3372](https://github.com/commercialhaskell/stack/issues/3372). * Fixes explanation of why a target is needed by the build plan, when the - target is an extra dependency from the commandline. + target is an extra-dep from the commandline. See [#3378](https://github.com/commercialhaskell/stack/issues/3378). * Previously, if you delete a yaml file from ~/.stack/build-plan, it would trust the etag and not re-download. Fixed in this version. @@ -2455,8 +2467,8 @@ * Overall it should now be able to initialize almost all existing Cabal packages out of the box as long as the package itself is consistently defined. - * Choose the best possible snapshot and add extra dependencies on top - of a snapshot resolver rather than a compiler resolver - + * Choose the best possible snapshot and add extra-deps on top + of a snapshot other than a compiler snapshot - [#1583](https://github.com/commercialhaskell/stack/pull/1583) * Automatically omit a package (`--omit-packages`) when it is compiler incompatible or when there are packages with conflicting dependency @@ -2923,7 +2935,7 @@ * Hacky workaround for optparse-applicative issue with `stack exec --help` [#806](https://github.com/commercialhaskell/stack/issues/806) -* Build executables for local extra deps +* Build executables for local extra-deps [#920](https://github.com/commercialhaskell/stack/issues/920) * copyFile can't handle directories [#942](https://github.com/commercialhaskell/stack/pull/942)
cabal.config view
@@ -130,7 +130,7 @@ , open-browser ==0.2.1.0 , optparse-applicative ==0.18.1.0 , optparse-simple ==0.1.1.4 - , pantry ==0.9.3.1 + , pantry ==0.9.3.2 , parsec ==3.1.16.1 , parser-combinators ==1.3.0 , path ==0.9.5 @@ -163,7 +163,7 @@ , socks ==0.6.1 , split ==0.2.5 , splitmix ==0.1.0.5 - , stack ==2.15.1 + , stack ==2.15.3 , static-bytes ==0.1.0 , stm ==2.5.1.0 , stm-chans ==3.0.0.9
doc/CONTRIBUTING.md view
@@ -285,21 +285,22 @@ Stack aims to depend on well-known packages. The specific versions on which it depends at any time are specified by `package.yaml` and `stack.yaml`. It does not aim to be compatible with more than one version of the `Cabal` package at -any time. At the time of writing (August 2023) the package versions are -primarily ones in Stackage snapshot LTS Haskell 21.8 (for GHC 9.4.5), together -with extra-deps to depend on the latest versions of `ansi-terminal`, `crypton` -(instead of `cryptonite`), `hpack`, `pantry` and `tar-conduit`. +any time. At the time of writing (February 2024) the package versions are +primarily ones in Stackage snapshot LTS Haskell 22.7 (for GHC 9.6.4), together +with extra-deps to depend on the latest version of `pantry` and `process`. A Stack executable makes use of Cabal (the library) through a small 'Setup' executable that it compiles from Haskell source code. The executable compiles that code with a dependency on the version of Cabal that ships with the -specified GHC compiler. Each release of Stack will aim to support all versions -of GHC and the Cabal package in Stackage snapshots published within seven years -of the release. For example, snapshot LTS Haskell 8.0, published on -12 February 2017, was the first LTS Haskell snapshot to provide GHC 8.0.2 which -comes with `base-4.9.1.0` and `Cabal-1.24.2.0`. Until, at least, -13 February 2024, Stack releases would aim to support the immediate -predecessor, GHC 8.0.1 and `base-4.9.0.0`, `Cabal-1.24.0.0` and Haddock 2.17.2. +specified GHC compiler. Each release of Stack will normally aim to support all +versions of GHC and the Cabal package in Stackage snapshots published within +seven years of the release. For example, snapshot LTS Haskell 10.0, published on +19 December 2017, was the first LTS Haskell snapshot to provide GHC 8.2.2 which +comes with `base-4.10.1.0` and `Cabal-2.0.1.1`. Normally, until, at least, +19 December 2024, Stack releases would aim to support the immediate +predecessor, GHC 8.0.2 and `base-4.9.1.0`, `Cabal-1.24.2.0` and Haddock 2.17.4. +However, the next version of Stack will drop support for versions of Cabal +before 2.2. `Cabal-2.2.0.0` was released with GHC 8.4.1 on 8 March 2018. When a version of the Stack executable actually ceases to support a version of GHC and `Cabal`, that should be recorded in Stack's @@ -548,8 +549,8 @@ `--pedantic` flag. The `unit-tests` job runs on a matrix of operating systems and Stack -project-level YAML configuration files (`stack.yaml`). It builds and tests Stack -with the following flags: `--haddock --no-haddock-deps`. +project-level YAML configuration files (`stack.yaml`, by default). It builds and +tests Stack with the following flags: `--haddock --no-haddock-deps`. Its approach to creating a cache depends on the operating system. Its 'Cache dependencies on Unix-like OS' step caches the Stack root on Unix-like operating
doc/ChangeLog.md view
@@ -1,19 +1,30 @@ # Changelog -## Unreleased changes +## v2.15.3 - 2024-03-07 Release notes: -**Changes since v2.15.1:** +* With one exception, this release fixes bugs. -Major changes: +**Changes since v2.15.1:** Behavior changes: -Other enhancements: +* `stack path --global-config`, `--programs`, and `--local-bin` no longer set + up Stack's environment. Bug fixes: +* Due to a bug, Stack 2.15.1 did not support versions of GHC before 8.2. Stack + now supports GHC versions from 8.0. +* `--haddock-for-hackage` does not ignore `--haddock-arguments`. +* On Windows, package locations that are Git repositories with submodules now + work as intended. +* The `ghc`, `runghc` and `runhaskell` commands accept `--package` values that + are a list of package names or package identifiers separated by spaces and, in + the case of package identifiers, in the same way as if they were specified as + targets to `stack build`. + ## v2.15.1 - 2024-02-09 Release notes: @@ -68,7 +79,7 @@ `1.24.0.0`. * Experimental: Add flag `--haddock-for-hackage` to Stack's `build` command (including the `haddock` synonym for `build --haddock`) to enable building - local packages with flags to generate Haddock documentation, and an archive + project packages with flags to generate Haddock documentation, and an archive file, suitable for upload to Hackage. The form of the Haddock documentation generated for other packages is unaffected. * Experimental: Add flag `--documentation` (`-d` for short) to Stack's `upload` @@ -89,7 +100,7 @@ key is introduced, to allow the notification to be muted if unwanted. * Add option `--filter <item>` to Stack's `ls dependencies text` command to filter out an item from the results, if present. The item can be `$locals` for - all local packages. + all project packages. * Add option `--snapshot` as synonym for `--resolver`. * Add the `config set snapshot` command, corresponding to the `config set resolver` command. @@ -222,8 +233,9 @@ `c2hs`, `cpphs`, `gcc`, `greencard`, `happy`, `hsc2hs`, `hscolour`, `ld`, `pkg-config`, `strip` and `tar`. If Cabal uses the program during the configuration step, the argument is passed to it. -* By default all `--PROG-option` options are applied to all local packages. This - behaviour can be changed with new configuration option `apply-prog-options`. +* By default all `--PROG-option` options are applied to all project packages. + This behaviour can be changed with new configuration option + `apply-prog-options`. * Add flag `--[no-]use-root` to `stack script` (default disabled). Used with `--compile` or `--optimize`, when enabled all compilation outputs (including the executable) are written to a script-specific location in the `scripts` @@ -243,8 +255,8 @@ * `stack build` with `--file-watch` or `--file-watch-poll` outputs 'pretty' error messages, as intended. See [#5978](https://github.com/commercialhaskell/stack/issues/5978). -* `stack build` unregisters any local packages for the sub libraries of a local - package that is to be unregistered. See +* `stack build` unregisters any project packages for the sub libraries of a + project package that is to be unregistered. See [#6046](https://github.com/commercialhaskell/stack/issues/6046). * The warning that sublibrary dependency is not supported is no longer triggered by internal libraries. @@ -254,7 +266,7 @@ Hackage-only release of the `stack` package: * Supports building against snapshot Stackage LTS Haskell 21.0 (GHC 9.4.5), - without extra deps. + without extra-deps. * Supports build with `persistent-2.14.5.0`, using CPP directives. * Supports build with `unix-compat-0.7`, by removing reliance on the module `System.PosixCompat.User` removed in that package. @@ -731,7 +743,7 @@ affect the Stackage Curator use case, but there is now an additional message letting the user know when a previously-failed test case is being rerun. -* Move configure information for local packages back to .stack-work to improve +* Move configure information for project packages back to .stack-work to improve caching. See [#4893](https://github.com/commercialhaskell/stack/issues/4893). @@ -917,7 +929,7 @@ * Support MX Linux in get-stack.sh. Fixes [#4769](https://github.com/commercialhaskell/stack/issues/4769). -* Defer loading up of files for local packages. This allows us to get +* Defer loading up of files for project packages. This allows us to get plan construction errors much faster, and avoid some unnecessary work when only building a subset of packages. This is especially useful for the curator use case. @@ -1625,7 +1637,7 @@ * `stack script` can now handle relative paths to source files. See [#3372](https://github.com/commercialhaskell/stack/issues/3372). * Fixes explanation of why a target is needed by the build plan, when the - target is an extra dependency from the commandline. + target is an extra-dep from the commandline. See [#3378](https://github.com/commercialhaskell/stack/issues/3378). * Previously, if you delete a yaml file from ~/.stack/build-plan, it would trust the etag and not re-download. Fixed in this version. @@ -2455,8 +2467,8 @@ * Overall it should now be able to initialize almost all existing Cabal packages out of the box as long as the package itself is consistently defined. - * Choose the best possible snapshot and add extra dependencies on top - of a snapshot resolver rather than a compiler resolver - + * Choose the best possible snapshot and add extra-deps on top + of a snapshot other than a compiler snapshot - [#1583](https://github.com/commercialhaskell/stack/pull/1583) * Automatically omit a package (`--omit-packages`) when it is compiler incompatible or when there are packages with conflicting dependency @@ -2923,7 +2935,7 @@ * Hacky workaround for optparse-applicative issue with `stack exec --help` [#806](https://github.com/commercialhaskell/stack/issues/806) -* Build executables for local extra deps +* Build executables for local extra-deps [#920](https://github.com/commercialhaskell/stack/issues/920) * copyFile can't handle directories [#942](https://github.com/commercialhaskell/stack/pull/942)
doc/GUIDE.md view
@@ -248,7 +248,7 @@ ~~~yaml resolver: - url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/21/8.yaml + url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/22/11.yaml packages: - . ~~~ @@ -256,15 +256,16 @@ The value of the [`resolver`](yaml_configuration.md#resolver) key tells Stack *how* to build your package: which GHC version to use, versions of package dependencies, and so on. Our value here says to use -[LTS Haskell 22.7](https://www.stackage.org/lts-22.7), which implies GHC 9.6.4 +[LTS Haskell 22.11](https://www.stackage.org/lts-22.11), which implies GHC 9.6.4 (which is why `stack build` installs that version of GHC if it is not already available to Stack). There are a number of values you can use for `resolver`, which we'll cover later. -The value of the `packages` key tells Stack which local packages to build. In -our simple example, we have only a single package in our project, located in the -same directory, so '`.`' suffices. However, Stack has powerful support for -multi-package projects, which we'll elaborate on as this guide progresses. +The value of the `packages` key tells Stack which project packages, located +locally, to build. In our simple example, we have only a single project package, +located in the same directory, so '`.`' suffices. However, Stack has powerful +support for multi-package projects, which we'll elaborate on as this guide +progresses. Another file important to the build is `package.yaml`. @@ -404,9 +405,9 @@ ~~~ This output means that the `text` package was downloaded, configured, built, and -locally installed. Once that was done, we moved on to building our local package -(`helloworld`). At no point did we need to ask Stack to build dependencies — it -does so automatically. +locally installed. Once that was done, we moved on to building our project +package (`helloworld`). At no point did we need to ask Stack to build +dependencies — it does so automatically. ### Listing Dependencies @@ -539,15 +540,15 @@ Continuous Integration (CI) setting, like on Travis. For example, command: ~~~text -stack --resolver lts-20.26 build +stack --snapshot lts-20.26 build # Downloaded lts-20.26 build plan. # build output ... ~~~ When passed on the command line, you also get some additional "short-cut" -versions of snapshots: `--resolver nightly` will use the newest Nightly snapshot -available, `--resolver lts` will use the newest LTS, and `--resolver lts-21` -will use the newest LTS in the 21.x series. The reason these are only available +versions of snapshots: `--snapshot nightly` will use the newest Nightly snapshot +available, `--snapshot lts` will use the newest LTS, and `--snapshot lts-22` +will use the newest LTS in the 22.x series. The reason these are only available on the command line and not in your `stack.yaml` file is that using them: 1. Will slow down your build (since Stack then needs to download information on @@ -557,11 +558,11 @@ ### Changing GHC versions -Finally, let's try using an older LTS snapshot. We'll use the newest 19.x +Finally, let's try using an older LTS snapshot. We'll use the newest 21.x snapshot with the command: ~~~text -stack --resolver lts-19 build +stack --snapshot lts-21 build # build output ... ~~~ @@ -676,7 +677,7 @@ Sometimes you may want to use a specific snapshot for your project instead of `stack init` picking one for you. You can do that by using -`stack init --resolver <snapshot>`. +`stack init --snapshot <snapshot>`. You can also init with a compiler snapshot if you do not want to use a Stackage snapshot. That will result in all of your project's dependencies being @@ -943,7 +944,7 @@ version, e.g. `stack build yesod-bin-1.4.14`. * This is almost identical to specifying a package name, except it will (1) choose the given version instead of latest, and (2) error out if the given - version conflicts with the version of a local package. + version conflicts with the version of a project package. * The most flexibility comes from specifying individual *components*, e.g. `stack build helloworld:test:helloworld-test` says "build the test suite component named helloworld-test from the helloworld package." @@ -951,10 +952,10 @@ type of component it is, e.g. `stack build helloworld:helloworld-test`, or even skip the package name entirely, e.g. `stack build :helloworld-test`. * Finally, you can specify individual *directories* to build to trigger building - of any local packages included in those directories or subdirectories. + of any project packages included in those directories or subdirectories. When you give no specific arguments on the command line (e.g., `stack build`), -it's the same as specifying the names of all of your local packages. If you +it's the same as specifying the names of all of your project packages. If you just want to build the package for the directory you're currently in, you can use `stack build .`. @@ -1083,9 +1084,10 @@ !!! note When adding upstream packages directly to your project it is important to - distinguish _local packages_ from the upstream _dependency packages_. - Otherwise you may have trouble running `stack ghci`. See - [stack.yaml documentation](yaml_configuration.md#packages) for more details. + distinguish _project packages_ located locally from the upstream + _dependency packages_. Otherwise you may have trouble running `stack ghci`. + See [stack.yaml documentation](yaml_configuration.md#packages) for more + details. ## Flags and GHC options @@ -1335,7 +1337,7 @@ !!! note If you have added packages to your project please make sure to mark them as - extra deps for faster and reliable usage of `stack ghci`. Otherwise GHCi may + extra-deps for faster and reliable usage of `stack ghci`. Otherwise GHCi may have trouble due to conflicts of compilation flags or having to unnecessarily interpret too many modules. See Stack's project-level [configuration](yaml_configuration.md#extra-deps) to learn how to @@ -1422,10 +1424,10 @@ ### Curation vs dependency solving * Stack uses 'curation' (snapshots and Stack's project-level configuration file - (`stack.yaml`) define precisely the set of packages available for a project). - The Stack team firmly believes that the majority of users want to simply - ignore dependency resolution nightmares and get a valid build plan from day - one. That's why we've made 'curation' the focus of Stack. + (`stack.yaml`, by default) define precisely the set of packages available for + a project). The Stack team firmly believes that the majority of users want to + simply ignore dependency resolution nightmares and get a valid build plan from + day one. That's why we've made 'curation' the focus of Stack. * Cabal (the tool) can use 'curation' too but its origins are in dependency solving.
doc/azure_ci.md view
@@ -131,26 +131,26 @@ ### Multiple GHC - parametrised builds For different GHC versions, you probably want to use different project-level -configuration files (`stack.yaml`). If you don't want to put a specific -`stack.yaml` for a particular snapshot and still want to test it, you have -specify your resolver argument in `ARGS` environment variable (you will see an -example below). +configuration files (`stack.yaml`, by default). If you don't want to put a +specific `stack.yaml` for a particular snapshot and still want to test it, you +have specify your snapshot argument in `ARGS` environment variable (you will see +an example below). ~~~yaml strategy: matrix: GHC 8.0: - ARGS: "--resolver lts-9" + ARGS: "--snapshot lts-9" GHC 8.2: - ARGS: "--resolver lts-11" + ARGS: "--snapshot lts-11" GHC 8.4: - ARGS: "--resolver lts-12" + ARGS: "--snapshot lts-12" GHC 8.6: - ARGS: "--resolver lts-14" + ARGS: "--snapshot lts-14" GHC 8.8: - ARGS: "--resolver lts-15" + ARGS: "--snapsht lts-15" nightly: - ARGS: "--resolver nightly" + ARGS: "--snapshot nightly" ~~~ ## Running tests
doc/build_command.md view
@@ -63,11 +63,11 @@ Similarly, if a benchmark component is targeted, it is built and run unless the running behaviour is disabled with the `--no-run-benchmarks` flag. -This ability to specify a component applies only to a local package. With +This ability to specify a component applies only to a project package. With dependencies, Stack will *always* build the library (if present) and all executables (if any), and ignore test suites and benchmarks. If you want more control over a package, you must add it to your `packages` setting in your -project-level configuration file (`stack.yaml`). +project-level configuration file (`stack.yaml`, by default). ## Target syntax @@ -75,15 +75,15 @@ supported syntaxes for targets are: * *package*, e.g. `stack build foobar`, is the most commonly used target. It - will try to find the package in the following locations: local packages, - extra deps, snapshots, and package index (e.g. Hackage). If it's found in - the package index, then the latest version of that package from the index is - implicitly added to your extra dependencies. + will try to find the package in the following locations: project packages, + extra-deps, the snapshot, and the package index (e.g. Hackage). If it's + found in the package index, then the latest version of that package from the + index is implicitly added as an extra-dep. - If the package is a local package, the library and executable components are - selected to be built. If the `--test` and `--bench` flags are set, then all - of the test suite and benchmark components, respectively, are selected to be - built. + If the package is a project package, the library and executable components + are selected to be built. If the `--test` and `--bench` flags are set, then + all of the test suite and benchmark components, respectively, are selected + to be built. If *package* is a GHC boot package (packages that come with GHC and are included in GHC's global package database), the behaviour can be complex. @@ -97,7 +97,7 @@ include directly most boot packages but some snapshots may include directly some boot packages. In particular, some snapshots include directly `Win32` (which is a boot package on Windows) while others do not. For example, if - `Cabal` (a boot package) is not a local package or an extra dep, then + `Cabal` (a boot package) is not a project package or an extra-dep, then `stack build Cabal` with Stackage snapshot LTS Haskell 20.25 will: * on Windows, try to build the latest version of `Cabal` in the package @@ -109,7 +109,7 @@ * *package identifier*, e.g. `stack build foobar-1.2.3`, is usually used to include specific package versions from the package index. - If the package name conflicts with that of a local package, then Stack + If the package name conflicts with that of a project package, then Stack fails with an error. Otherwise, this is the same as using `stack build foobar` (that is, ignoring @@ -140,11 +140,11 @@ example, `stack build mypackage:mytestsuite`. * `:<comp-name>` is a useful shortcut, saying "find the component - `<comp-name>` in all of the local packages". This will result in an + `<comp-name>` in all of the project packages". This will result in an error if more than one package has a component with the specified name. To continue the above example, `stack build :mytestsuite`. -* *directory*, e.g. `stack build foo/bar`, will find all local packages that +* *directory*, e.g. `stack build foo/bar`, will find all project packages that exist in the given directory hierarchy and then follow the same procedure as passing in package names as mentioned above. There's an important caveat here: if your directory name is parsed as one of the above target types, it @@ -153,10 +153,10 @@ !!! note - `stack build .` will target local packages in the current working + `stack build .` will target project packages in the current working directory or its subdirectories. -`stack build` with no targets specified will build all local packages. +`stack build` with no targets specified will build all project packages. For further information about available targets, see the [`stack ide targets` command](ide_command.md). @@ -205,12 +205,8 @@ stack build --flag *:[-]<flag_name> ~~~ -!!! note - - Currently you needs to list all of your modules that interpret flags in the - `other-modules` section of a Cabal file. Cabal (the tool) has a different - behavior currently and doesn't require that the modules be listed. This may - change in a future release. +In order to set a Cabal flag for a GHC boot package, the package must be +specified as an extra-dep. ### `--[no-]force-dirty` flag @@ -271,11 +267,11 @@ Default: Disabled -Set the flag to build local packages with flags to generate Haddock +Set the flag to build project packages with flags to generate Haddock documentation suitable for upload to Hackage. The form of the Haddock documentation generated for other packages is unaffected. -For each local package: +For each project package: * the generated Haddock documentation files are in directory `doc\html\<package_version>-docs\`, relative to Stack's dist work directory @@ -387,7 +383,7 @@ ### `--skip` option `stack build --skip <component>` skips building the specified components of a -local package. It allows you to skip test suites and benchmark without +project package. It allows you to skip test suites and benchmark without specifying other components (e.g. `stack test --skip long-test-suite` will run the tests without the `long-test-suite` test suite). Be aware that skipping executables won't work the first time the package is built due to an issue in @@ -418,7 +414,8 @@ [:octicons-tag-24: 2.5.1](https://github.com/commercialhaskell/stack/releases/tag/v2.5.1) Pass the flag to rebuild your project every time any local file changes (from -project packages or from local dependencies). See also the `--file-watch` flag. +project packages or from dependencies located locally). See also the +`--file-watch` flag. ## Controlling what happens after building @@ -492,9 +489,11 @@ ### `--ghc-options` option -Augment and, if applicable, override any GHC command line options specified in -Cabal files (including those created from `package.yaml` files) or in Stack's -YAML configuration files. +GHC command line options can be specified for a package in its Cabal file +(including one created from a `package.yaml` file). This option augments and, if +applicable (see below), overrides any such GHC command line options and those +specified in Stack's YAML configuration files - see the +[`ghc-options`](yaml_configuration.md#ghc-options) configuration option. `stack build --ghc-options <ghc_options>` passes the specified command line options to GHC, depending on Stack's @@ -576,7 +575,7 @@ to `happy` its `--ghc` flag. By default, all and any `--PROG-option` options on Stack's command line are -applied to all local packages (targets or otherwise). This behaviour can be +applied to all project packages (targets or otherwise). This behaviour can be changed. See the [`apply-prog-options`](yaml_configuration.md#apply-prog-options) configuration option. @@ -807,14 +806,14 @@ the most recent Stackage Nightly snapshot: ~~~text - stack --resolver nightly install Agda-2.6.3 + stack --snapshot nightly install Agda-2.6.3 ~~~ Alternatively, Stack can be used to unpack the package from the package index into a local project directory named after the package identifier (for further infomation, see the [`stack unpack` command](unpack_command.md) documentation) and, if the package does not provide its own Stack - configuration file (`stack.yaml`), to attempt to initialise that + configuration file (`stack.yaml`, by default), to attempt to initialise that configuration (for further information, see the [`stack init` command](init_command.md) documentation). For example:
doc/build_overview.md view
@@ -72,7 +72,7 @@ ## Wanted compiler, dependencies, and project packages -* If the `--resolver` CLI is present, ignore the `snapshot` (or `resolver`) and +* If the `--snapshot` CLI is present, ignore the `snapshot` (or `resolver`) and `compiler` config values * Load up the indicated snapshot (either config value or CLI arg). This will provide: @@ -81,7 +81,7 @@ are immutable. * A wanted compiler version, e.g. `ghc-8.6.5` * If the `--compiler` CLI arg is set, or the `compiler` config value - is set (and `--resolver` CLI arg is not set), ignore the wanted + is set (and `--snapshot` CLI arg is not set), ignore the wanted compiler from the snapshot and use the specified wanted compiler * Parse `extra-deps` into a `Map PackageName PackageLocation`, containing both mutable and immutable package locations. Parse
doc/config_command.md view
@@ -23,7 +23,8 @@ `stack config env` outputs a script that sets or unsets environment variables for a Stack environment. Flags modify the script that is output: -* `--[no-]locals` (enabled by default) include/exclude local package information +* `--[no-]locals` (enabled by default) include/exclude project package + information * `--[no-]ghc-package-path` (enabled by default) set `GHC_PACKAGE_PATH` environment variable or not * `--[no-]stack-exe` (enabled by default) set `STACK_EXE` environment variable @@ -59,8 +60,8 @@ `stack config set install-ghc true` or `false` sets the `install-ghc` key in a YAML configuration file, accordingly. By default, the project-level -configuration file (`stack.yaml`) is altered. The `--global` flag specifies the -user-specific global configuration file (`config.yaml`). +configuration file (`stack.yaml`, by default) is altered. The `--global` flag +specifies the user-specific global configuration file (`config.yaml`). ## The `stack config set package-index download-prefix` command @@ -72,9 +73,9 @@ `stack config set package-index download-prefix <url>` sets the `download-prefix` key of the `package-index` key in a YAML configuration file, -accordingly. By default, the project-level configuration file (`stack.yaml`) is -altered. The `--global` flag specifies the user-specific global configuration -file (`config.yaml`). +accordingly. By default, the project-level configuration file (`stack.yaml`, by +default) is altered. The `--global` flag specifies the user-specific global +configuration file (`config.yaml`). ## The `stack config set resolver` command @@ -83,7 +84,7 @@ ~~~ `stack config set resolver <snapshot>` sets the `resolver` key in the -project-level configuration file (`stack.yaml`). +project-level configuration file (`stack.yaml`, by default). A snapshot of `lts` or `nightly` will be translated into the most recent available. A snapshot of `lts-22` will be translated into the most recent @@ -102,7 +103,7 @@ ~~~ `stack config set snapshot <snapshot>` sets the `snapshot` key in the -project-level configuration file (`stack.yaml`). +project-level configuration file (`stack.yaml`, by default). A snapshot of `lts` or `nightly` will be translated into the most recent available. A snapshot of `lts-22` will be translated into the most recent @@ -120,5 +121,5 @@ `stack config set system-ghc true` or `false` sets the `system-ghc` key in a YAML configuration file, accordingly. By default, the project-level -configuration file (`stack.yaml`) is altered. The `--global` flag specifies the -user-specific global configuration file (`config.yaml`). +configuration file (`stack.yaml`, by default) is altered. The `--global` flag +specifies the user-specific global configuration file (`config.yaml`).
doc/dev_containers.md view
@@ -9,8 +9,8 @@ Stack provides the following Dev Containers: -* a default Dev Container, intended for use with Stack's project‑level - configuration (`stack.yaml`); and +* a default Dev Container, intended for use with Stack's default project‑level + configuration file (`stack.yaml`); and * alternative Dev Containers, intended for use with Stack's experimental project‑level configurations (in anticipation of building Stack with more recent versions of GHC).
doc/faq.md view
@@ -14,8 +14,8 @@ the snapshot in more detail. The snapshot is determined by finding the relevant project-level configuration -file (`stack.yaml`) for the directory you're running the command from. This -essentially works by: +file (`stack.yaml`, by default) for the directory you're running the command +from. This essentially works by: 1. Check for a `STACK_YAML` environment variable or the `--stack-yaml` command line argument @@ -32,7 +32,7 @@ outside of a project: ~~~text -stack config set resolver lts +stack config set snapshot lts ~~~ ## Where is Stack installed and will it interfere with the GHC (etc) I already have installed? @@ -298,8 +298,8 @@ ## I have a custom package index I'd like to use, how do I do so? -You can configure this in your project-level configuration file (`stack.yaml`). -See [YAML configuration](yaml_configuration.md). +You can configure this in your project-level configuration file (`stack.yaml`, +by default). See [YAML configuration](yaml_configuration.md). ## How can I make sure my project builds against multiple GHC versions? @@ -427,10 +427,9 @@ ## Why doesn't Stack apply my `--ghc-options` to my dependencies? -By default, Stack applies command line GHC options only to local packages (these -are all the packages that are specified in the `packages` section of your -`stack.yaml` file). For an explanation of this choice see this discussion on -issue +By default, Stack applies command line GHC options only to +[project packages](yaml_configuration.md#packages). For an explanation of this +choice see this discussion on issue [#827](https://github.com/commercialhaskell/stack/issues/827#issuecomment-133263678). If you still want to set specific GHC options for a dependency, use the
doc/ghc_command.md view
@@ -12,8 +12,10 @@ [`stack exec ghc`](exec_command.md), with the exception of the `--package` option. -Pass the option `--package <package>` to add the initial GHC argument +Pass the option `--package <package(s)>` to add the initial GHC argument `-package-id=<unit_id>`, where `<unit_id>` is the unit ID of the specified -package in the installed package database. The option can be specified multiple -times. The approach taken to these packages is the same as if they were -specified as targets to [`stack build`](build_command.md#target-syntax). +package in the installed package database. The option can be a list of package +names or package identifiers separated by spaces. The option can also be +specified multiple times. The approach taken to these packages is the same as if +they were specified as targets to +[`stack build`](build_command.md#target-syntax).
doc/ghci.md view
@@ -97,6 +97,24 @@ stack ghci --package lens ~~~ +## Specifying Cabal flags + +`--flag <package_name>:[-]<flag_name>` sets (or unsets) the specified Cabal flag +for the specified package. + +This option can be specified multiple times to set (or unset) multiple Cabal +flags. + +The same Cabal flag name can be set (or unset) for multiple packages with: + +~~~text +--flag *:[-]<flag_name> +~~~ + +In order to set a Cabal flag for a GHC boot package, the package must either be +an extra-dep or the package version must be specified with the `--package` +option. + ## Running plain GHCi `stack ghci` always runs GHCi configured to load code from packages in your
doc/global_flags.md view
@@ -54,9 +54,10 @@ Default: Dump warning logs -Enables/disables the dumping of the build output logs for local packages to the -console. For further information, see the documentation for the corresponding -non-project specific configuration [option](yaml_configuration.md#dump-logs). +Enables/disables the dumping of the build output logs for project packages to +the console. For further information, see the documentation for the +corresponding non-project specific configuration +[option](yaml_configuration.md#dump-logs). ## `--extra-include-dirs` option @@ -210,8 +211,10 @@ Default: Disabled -Enables/disables the skipping of installing MSYS2. For further information, see -the documentation for the corresponding non-project specific configuration +Enables/disables the skipping of checking for the Stack-supplied MSYS2 (and +installing that MSYS2, if it is not installed) when Stack is setting up the +environment. For further information, see the documentation for the +corresponding non-project specific configuration [option](yaml_configuration.md#skip-msys). ## `--snapshot` option @@ -227,8 +230,12 @@ * `--snapshot lts-<major_version>` specifies the latest Stackage LTS Haskell snapshot with the specified major version; * `--snapshot lts` specifies, from those with the greatest major version, the - latest Stackage LTS Haskell snapshot; and -* `--snapshot nightly` specifies the most recent Stackage Nightly snapshot. + latest Stackage LTS Haskell snapshot; +* `--snapshot nightly` specifies the most recent Stackage Nightly snapshot; + and +* `--snapshot global` specifies the snapshot specified by the project-level + configuration file in the `global-project` directory in the + [Stack root](stack_root.md#global-project-directory). ## `--stack-colors` or `--stack-colours` options
doc/glossary.md view
@@ -12,9 +12,10 @@ |CI |Continuous integration. | |CMake |A [system](https://cmake.org/) for managing build processes.| |`config.yaml` |A global and non-project-specific configuration file used by Stack.| +|dependency |A Haskell package other than a project package and on which a project package depends (directly or indirectly), located locally or elsewhere.| |Docker |A [platform](https://www.docker.com/) for developing, shipping, and running applications. It can package and run an application in a loosely isolated environment called a _container_.| |Emacs |[GNU Emacs](https://www.gnu.org/software/emacs/), an extensible, customisable text editor.| -|extra-deps |Packages (one version of each) that add to, or amend, those specified in a snapshot. Named after a key used in `stack.yaml` files.| +|extra-deps |Extra dependencies (one version of each) that add to, or shadow, those specified in a snapshot.| |FreeBSD |A Unix-like operating system. | |GCC |The [GNU Compiler Collection](https://gcc.gnu.org/) or its executable `gcc`.| |GHC |The [Glasgow Haskell Compiler](https://www.haskell.org/ghc/).| @@ -40,7 +41,8 @@ |`package.yaml` |A file that describes a package in the Hpack format. | |Pantry |A library for content-addressable Haskell package management, provided by the [`pantry` package](https://hackage.haskell.org/package/pantry). A dependency of Stack.| |PATH |The `PATH` environment variable, specifying a list of directories searched for executable files.| -|project |A Stack project is a local directory that contains a project-level configuration file (`stack.yaml`). A project may relate to more than one local package.| +|project |A Stack project is a local directory that contains a project-level configuration file (`stack.yaml`, by default). A project may relate to more than one project package.| +|project package |A Haskell package that is part of a project and located locally. Distinct from a dependency located locally.| |PVP |The Haskell [Package Versioning Policy](https://pvp.haskell.org/), which tells developers of libraries how to set their version numbers.| |REPL |An interactive (run-eval-print loop) programming environment.| |resolver |A synonym for snapshot. |
doc/hpc_command.md view
@@ -90,7 +90,7 @@ `stack test --coverage` is quite streamlined for the following use-case: -1. You have test suites which exercise your local packages. +1. You have test suites which exercise your project packages. 2. These test suites link against your library, rather than building the library directly. Coverage information is only given for libraries, ignoring @@ -119,12 +119,12 @@ Most users can get away with just understanding the above documentation. However, advanced users may want to understand exactly how `--coverage` works: -1. The GHC option `-fhpc` gets passed to all local packages. This tells GHC to +1. The GHC option `-fhpc` gets passed to all project packages. This tells GHC to output executables that track coverage information and output them to `.tix` files. `the-exe-name.tix` files will get written to the working directory of the executable. - When switching on this flag, it will usually cause all local packages to be + When switching on this flag, it will usually cause all project packages to be rebuilt (see issue [#1940](https://github.com/commercialhaskell/stack/issues/1940)). @@ -145,7 +145,7 @@ the modules compiled in the `executable` or `test-suite` stanza of your Cabal file. This makes it possible to directly union multiple `*.tix` files from different executables (assuming they are using the exact same versions of the - local packages). + project packages). If there is enough popular demand, it may be possible in the future to give coverage information for modules that are compiled directly into the
doc/ide_command.md view
@@ -20,7 +20,7 @@ stack ide packages [--stdout] [--cabal-files] ~~~ -`stack ide packages` lists all available local packages that are loadable. +`stack ide packages` lists all available project packages that are loadable. By default:
doc/init_command.md view
@@ -6,7 +6,7 @@ stack init [DIR(S)] [--omit-packages] [--force] [--ignore-subdirs] ~~~ -`stack init` initialises Stack's project-level YAML configuration file +`stack init` initialises Stack's default project-level YAML configuration file (`stack.yaml`) for an existing project, based on the Cabal file or `package.yaml` file for each of its packages. @@ -24,3 +24,13 @@ * Stack will not initialise if there are conflicting or incompatable user packages. Pass the flag `--omit-packages` to cause Stack to ignore such matters while initialising. + +If a snapshot is specified at the command line, `stack init` will try to use it. +For further information, see the documentation for the +[`--snapshot`](global_flags.md#-snapshot-option) and +[`--resolver`](global_flags.md#-resolver-option) options. + +Otherwise, `stack init` will try to use the following Stackage snapshots in +order of preference, using the first that is compatable: the most recent LTS +Haskell, the most recent Stackage Nightly, and other LTS Haskell (most recent +first).
doc/install_and_upgrade.md view
@@ -118,22 +118,75 @@ sudo apt-get install g++ gcc libc6-dev libffi-dev libgmp-dev make xz-utils zlib1g-dev git gnupg netbase ~~~ + === "AArch64" + + * Click + [:material-cloud-download-outline:](https://get.haskellstack.org/stable/linux-aarch64.tar.gz) + to download an archive file with the latest release. + + * Extract the archive and place the `stack` executable somewhere on your + PATH (see the [Path](#path) section below). + + * Ensure you have the required system dependencies installed. These + include GCC, GNU Make, xz, perl, libgmp, libffi, and zlib. We also + recommend Git and GPG. + + The installation of system dependencies will depend on the package + manager for your Linux distribution. Notes are provided for Arch Linux, + CentOS, Debian, Fedora, Gentoo and Ubuntu. + + === "Arch Linux" + + ~~~text + sudo pacman -S make gcc ncurses git gnupg xz zlib gmp libffi zlib + ~~~ + + === "CentOS" + + ~~~text + sudo yum install perl make automake gcc gmp-devel libffi zlib zlib-devel xz tar git gnupg + ~~~ + + === "Debian" + + ~~~text + sudo apt-get install g++ gcc libc6-dev libffi-dev libgmp-dev make xz-utils zlib1g-dev git gnupg netbase + ~~~ + + === "Fedora" + + ~~~text + sudo dnf install perl make automake gcc gmp-devel libffi zlib zlib-devel xz tar git gnupg + ~~~ + + === "Gentoo" + + Ensure you have the `ncurses` package with `USE=tinfo`. Without it, + Stack will not be able to install GHC. + + === "Ubuntu" + + ~~~text + sudo apt-get install g++ gcc libc6-dev libffi-dev libgmp-dev make xz-utils zlib1g-dev git gnupg netbase + ~~~ + ### Linux packages Some Linux distributions have official or unofficial packages for Stack, including Arch Linux, Debian, Fedora, NixOS, openSUSE/SUSE Linux Enterprise, - and Ubuntu. + and Ubuntu. However, the Stack version available as a Linux package may lag + behind Stack's current version and, in some cases, the lag may be + significant. !!! info "Linux packages that lag behind Stack's current version" - The Stack version available as a Linux package may lag behind Stack's - current version. If so, using `stack upgrade --binary-only` is - recommended after installing it. For Stack versions before 1.3.0 which - do not support `--binary-only`, just `stack upgrade` may work too. + If Stack version available as a Linux package lags behind Stack's + current version, using `stack upgrade --binary-only` is recommended + after installing it. === "Arch Linux" - The Arch extra package repository provides an official + The Arch extra package repository provides an official x86_64 [package](https://www.archlinux.org/packages/extra/x86_64/stack/). You can install it with the command: @@ -141,27 +194,18 @@ sudo pacman -S stack ~~~ - This version may slightly lag behind, but it should be updated within - the day. The package is also always rebuilt and updated when one of its - dependencies gets an update. + The Arch User Repository (AUR) also provides: - The Arch User Repository (AUR) also provides a - [package](https://aur.archlinux.org/packages/haskell-stack-git). - However, its Stack version lags behind, so running - `stack upgrade --binary-only` is recommended after installing it. For - older Stack versions which do not support `--binary-only`, just - `stack upgrade` may work too. + * a [`stack-bin` package](https://aur.archlinux.org/packages/stack-bin); + and - To use `stack setup` with versions of GHC before 7.10.3 or on a - 32-bit system, you may need the AUR - [ncurses5-compat-libs](https://aur.archlinux.org/packages/ncurses5-compat-libs/) - package installed. + * a [`stack-static` package](https://aur.archlinux.org/packages/stack-static) === "Debian" There are Debian [packages](https://packages.debian.org/search?keywords=haskell-stack&searchon=names&suite=all§ion=all) - for Stretch and up. However, the distribution's Stack version lags + for Buster and up. However, the distribution's Stack version lags behind. === "Fedora" @@ -234,8 +278,7 @@ There are Ubuntu [packages](http://packages.ubuntu.com/search?keywords=haskell-stack&searchon=names&suite=all§ion=all) - for Ubuntu 18.04 and up. However, the distribution's Stack version lags - behind. + for Ubuntu 20.04 and up. It is possible to set up auto-completion of Stack commands. For further information, see the [shell auto-completion](shell_autocompletion.md) @@ -357,6 +400,21 @@ [Path](#path) section below). * Now you can run Stack from the command line in a terminal. + + ### LLVM + + The documentation for each version of GHC identifies the versions of + LLVM that are supported. That is summarised in the table below for + recent versions of GHC: + + |GHC version|LLVM versions| + |-----------|-------------| + |9.8.2 |11 to 15 | + |9.6.4 |11 to 15 | + |9.4.8 |10 to 14 | + |9.2.8 |9 to 12 | + |9.0.2 |9, 10 or 12 | + |8.10.7 |9 to 12 | ### Using Homebrew
doc/list_command.md view
@@ -13,7 +13,7 @@ Hackage, even after updating the package index, suggestions (not necessarily good ones) will be made about the intended package name. -`stack --resolver <snapshot> list <package_name>` will send to the standard +`stack --snapshot <snapshot> list <package_name>` will send to the standard output stream the version of the package in the specified snapshot, unless the package comes with GHC on Unix-like operating systems. If the package name cannot be found in the snapshot, the command will fail, identifying only the @@ -21,7 +21,7 @@ More than one package name can be specified. -`stack --resolver <snapshot> list` will send to the standard output stream a +`stack --snapshot <snapshot> list` will send to the standard output stream a list of all the packages in the specified snapshot, except those which come with GHC on Unix-like operating systems. @@ -44,17 +44,17 @@ pantry, pretty, pasty, xattr, alloy, para, pappy, alure, polar and factory. -stack --resolver lts-22.7 list base unix Win32 acme-missiles pantry +stack --snapshot lts-22.7 list base unix Win32 acme-missiles pantry Error: [S-4926] * Package does not appear in snapshot: base. * Package does not appear in snapshot: unix. * Package does not appear in snapshot: Win32. * Package does not appear in snapshot: acme-missiles. -stack --resolver lts-22.7 list pantry +stack --snapshot lts-22.7 list pantry pantry-0.9.3.1 -stack --resolver lts-22.7 list +stack --snapshot lts-22.7 list AC-Angle-1.0 ALUT-2.4.0.3 ...
doc/lock_files.md view
@@ -21,7 +21,7 @@ * These files can be stored in source control * Users on other machines can reuse these lock files and get identical build - plans given that the used local packages and local snapshots are the same on + plans given that the used project packages and local snapshots are the same on those machines * Rerunning `stack build` in the future is deterministic in the build plan, not depending on mutable state in the world like Hackage revisions @@ -39,7 +39,7 @@ ## stack.yaml and snapshot files Relevant to this discussion, Stack's project-level configuration file -(`stack.yaml`) specifies: +(`stack.yaml`, by default) specifies: * the parent snapshot (the [`snapshot`](yaml_configuration.md#snapshot) or [`resolver`](yaml_configuration.md#resolver) key) @@ -103,7 +103,7 @@ The lock file contains the following information: -* Completed package locations for extra deps and packages in snapshot files +* Completed package locations for extra-deps and packages in snapshot files !!! note @@ -148,9 +148,9 @@ ## Creation procedure -Whenever a project-level configuration file (`stack.yaml`) is loaded, Stack -checks for a lock file in the same file path, with a `.lock` extension added. -For example, if you command: +Whenever a project-level configuration file (`stack.yaml`, by default) is +loaded, Stack checks for a lock file in the same file path, with a `.lock` +extension added. For example, if you command: ~~~text stack --stack-yaml my-stack.yaml build @@ -177,9 +177,9 @@ ## Update procedure -Whenever a project-level configuration file (`stack.yaml`) is loaded, all -completed package or snapshot locations (even those completed using information -from a lock file) get collected to form a new lock file in memory. Subject to -Stack's [`--lock-file`](global_flags.md#-lock-file-option) option, that new lock -file is compared against the one on disk and, if there are any differences, -written out to the disk. +Whenever a project-level configuration file (`stack.yaml`, by default) is +loaded, all completed package or snapshot locations (even those completed using +information from a lock file) get collected to form a new lock file in memory. +Subject to Stack's [`--lock-file`](global_flags.md#-lock-file-option) option, +that new lock file is compared against the one on disk and, if there are any +differences, written out to the disk.
doc/ls_command.md view
@@ -40,7 +40,7 @@ ~~~ `stack ls dependencies` lists all of the packages and versions used for a -project. All local packages are considered by default, but a target can be +project. All project packages are considered by default, but a target can be specified as an argument. For further information, see the [target syntax](build_command.md#target-syntax) documentation. @@ -144,7 +144,7 @@ The `--filter` option, with the `text` subcommand, specifies an item to be filtered out from the results, if present. An item can be `$locals` (for all -local packages) or a package name. It can be specified multiple times. +project packages) or a package name. It can be specified multiple times. !!! note
doc/new_command.md view
@@ -13,10 +13,13 @@ By default: * the project is created in a new directory named after the package. Pass the - `--bare` flag to create the project in the current directory; and + `--bare` flag to create the project in the current directory; * the project is initialised for use with Stack. Pass the `--no-init` flag to - skip such initialisation. + skip such initialisation; and + +* the project template is the one specified by the +[default-template](yaml_configuration.md#default-template) option. A package name acceptable to Cabal comprises an alphanumeric 'word'; or two or more such words, with the words separated by a hyphen/minus character (`-`). A
doc/nix_integration.md view
@@ -128,7 +128,7 @@ hPkgs = pkgs.haskell.packages."ghc8107"; # need to match Stackage LTS version - # from stack.yaml snapshot resolver + # from stack.yaml snapshot myDevTools = [ hPkgs.ghc # GHC compiler in the desired version (will be available on PATH) @@ -310,8 +310,8 @@ Stack expects the `shell.nix` file to define a function of with one argument called `ghc` (arguments are not positional), which you should give to function `buildStackProject`. This argument is a GHC Nix package in the -version as defined in the resolver you set in Stack's project-level -configuration file (`stack.yaml`). +version as defined in the snapshot you set in Stack's project-level +configuration file (`stack.yaml`, by default). ### Pure and impure Nix shells @@ -377,7 +377,8 @@ Below is a summary of the non-project specific configuration options and their default values. The options can be set in Stack's project-level configuration -file (`stack.yaml`) or its global configuration file (`config.yaml`). +file (`stack.yaml`, by default) or its global configuration file +(`config.yaml`). ~~~yaml nix:
doc/nonstandard_project_init.md view
@@ -3,7 +3,8 @@ # Non-standard project initialization You may need to configure Stack to work with an existing project that has one or -more Cabal files but no Stack project-level configuration file (`stack.yaml`). +more Cabal files but no Stack project-level configuration file (`stack.yaml`, by +default). ## The `stack init` command
doc/pantry.md view
@@ -27,7 +27,7 @@ for example: ~~~yaml - snapshot: ghc-8.6.5` + snapshot: ghc-8.6.5 ~~~ 2. Via a URL pointing to a snapshot configuration file, for example:
doc/path_command.md view
@@ -3,9 +3,9 @@ # The `stack path` command ~~~text -stack path [--stack-root] [--global-config] [--project-root] [--config-location] - [--bin-path] [--programs] [--compiler-exe] [--compiler-bin] - [--compiler-tools-bin] [--local-bin] [--extra-include-dirs] +stack path [--stack-root] [--global-config] [--programs] [--local-bin] + [--project-root] [--config-location] [--bin-path] [--compiler-exe] + [--compiler-bin] [--compiler-tools-bin] [--extra-include-dirs] [--extra-library-dirs] [--snapshot-pkg-db] [--local-pkg-db] [--global-pkg-db] [--ghc-package-path] [--snapshot-install-root] [--local-install-root] [--snapshot-doc-root] [--local-doc-root] @@ -22,7 +22,7 @@ |--compiler-bin |The directory containing the GHC executable. | |--compiler-exe |The GHC executable. | |--compiler-tools-bin |The directory containing binaries specific to a particular compiler.| -|--config-location |Stack's project-level YAML configuration file (`stack.yaml`).| +|--config-location |Stack's project-level YAML configuration file (`stack.yaml`, by default).| |--dist-dir |The dist work directory, relative to the package directory.| |--extra-include-dirs |Extra include directories. | |--extra-library-dirs |Extra library directories. |
doc/query_command.md view
@@ -12,7 +12,7 @@ `stack query` outputs certain build information. For example, for a multi-package project `multi` specifying snapshot `lts-19.25` (GHC 9.0.2) and -with two local packages, `my-package-A` (version 0.1.0.0) and `my-package-B` +with two project packages, `my-package-A` (version 0.1.0.0) and `my-package-B` (version 0.2.0.0), command `stack query` outputs: ~~~text
doc/runghc_command.md view
@@ -13,8 +13,10 @@ [`stack exec runghc`](exec_command.md), with the exception of the `--package` option. -Pass the option `--package <package>` to add the initial GHC argument +Pass the option `--package <package(s)>` to add the initial GHC argument `-package-id=<unit_id>`, where `<unit_id>` is the unit ID of the specified -package in the installed package database. The option can be specified multiple -times. The approach taken to these packages is the same as if they were -specified as targets to [`stack build`](build_command.md#target-syntax). +package in the installed package database. The option can be a list of package +names or package identifiers separated by spaces. The option can also be +specified multiple times. The approach taken to these packages is the same as if +they were specified as targets to +[`stack build`](build_command.md#target-syntax).
doc/script_command.md view
@@ -15,10 +15,10 @@ Unlike `stack ghc` and `stack runghc`, the command ignores all Stack YAML configuration files (global and project-level). A snapshot must be specified on -the command line (with the `--resolver` option). For example: +the command line (with the `--snapshot` option). For example: ~~~text -stack script --resolver lts-22.7 MyScript.hs +stack script --snapshot lts-22.7 MyScript.hs ~~~ The `stack script` command behaves as if the `--install-ghc` flag had been @@ -100,7 +100,7 @@ can be compiled and run, with arguments, with: ~~~text -stack --resolver lts-22.7 script --package acme-missiles --compile MyScript.hs -- "Don't panic!" "Duck and cover!" +stack --snapshot lts-22.7 script --package acme-missiles --compile MyScript.hs -- "Don't panic!" "Duck and cover!" ~~~ All the compilation outputs (like `Main.hi`, `Main.o`, and the executable @@ -123,7 +123,7 @@ ~~~haskell {- stack script - --resolver lts-20.25 + --snapshot lts-20.25 --extra-dep acme-missiles-0.3 --extra-dep directory-1.3.6.2 --extra-dep process-1.6.16.0 @@ -138,17 +138,17 @@ ~~~ `acme-missiles` is not in the snapshot and so needs to be specified as an - extra dep. + extra-dep. Stack can deduce that the module imports imply that the required packages are `acme-missiles`, `time` and `extra` (which is in the snapshot). `extra` depends on `directory` and `process`. If `directory` and `process` - are not specified as extra deps, Stack will complain that they have been + are not specified as extra-deps, Stack will complain that they have been 'pruned'. `directory-1.3.6.2` depends on `time < 1.12`. If `time` is not specified as - an extra dep, Stack will try to construct a build plan based on the latest + an extra-dep, Stack will try to construct a build plan based on the latest version in the package index (which will fail, as the latest version is `>= 1.12`) @@ -156,7 +156,7 @@ ~~~haskell {- stack script - --resolver lts-20.25 + --snapshot lts-20.25 --extra-dep acme-missiles-0.3 -} @@ -168,7 +168,7 @@ ~~~ `acme-missiles` is not in the snapshot and so needs to be specified as an - extra dep. + extra-dep. Stack can deduce that the module imports imply that the required packages are `acme-missiles`, `time` and `extra` (which is in the snapshot).
doc/scripts.md view
@@ -19,7 +19,7 @@ ~~~haskell #!/usr/bin/env stack --- stack script --resolver lts-22.7 --package turtle +-- stack script --snapshot lts-22.7 --package turtle {-# LANGUAGE OverloadedStrings #-} import Turtle (echo) main = echo "Hello World!" @@ -78,7 +78,7 @@ The second line of the source code is the Stack interpreter options comment. In this example, it specifies the `stack script` command with the options of a -LTS Haskell 22.7 snapshot (`--resolver lts-22.7`) and ensuring the +LTS Haskell 22.7 snapshot (`--snapshot lts-22.7`) and ensuring the [`turtle` package](https://hackage.haskell.org/package/turtle) is available (`--package turtle`). The version of the package will be that in the specified snapshot (`lts-22.7` provides `turtle-1.6.2`). @@ -116,7 +116,7 @@ ~~~haskell #!/usr/bin/env stack {- stack script - --resolver lts-22.7 + --snapshot lts-22.7 -- +RTS -s -RTS -} @@ -132,7 +132,7 @@ is equivalent to the following command at the command line: ~~~text -stack script --resolver lts-22.7 -- MyScript.hs arg1 arg2 +RTS -s -RTS +stack script --snapshot lts-22.7 -- MyScript.hs arg1 arg2 +RTS -s -RTS ~~~ where `+RTS -s -RTS` are some of GHC's @@ -161,7 +161,7 @@ ~~~haskell #!/usr/bin/env stack {- stack script - --resolver lts-22.7 + --snapshot lts-22.7 --package turtle --package "stm async" --package http-client,http-conduit @@ -191,7 +191,7 @@ ~~~haskell {- stack script - --resolver lts-22.7 + --snapshot lts-22.7 --package acme-missiles -} import Acme.Missiles (launchMissiles) @@ -202,7 +202,7 @@ The command `stack --script-no-run-compile Script.hs` then behaves as if the command -`stack script --resolver lts-22.7 --package acme-missiles --no-run --compile -- Script.hs` +`stack script --snapshot lts-22.7 --package acme-missiles --no-run --compile -- Script.hs` had been given. `Script.hs` is compiled (without optimisation) and the resulting executable is not run: no missiles are launched in the process! @@ -227,7 +227,7 @@ 2. Explicitly specify all packages required by the script using the `--package` option. Use `-hide-all-packages` GHC option to force explicit specification of all packages. -3. Use the `--resolver` Stack option to ensure a specific GHC version and +3. Use the `--snapshot` Stack option to ensure a specific GHC version and package set is used. It is possible for configuration files to affect `stack runghc`. For that @@ -239,7 +239,7 @@ {- stack runghc --install-ghc - --resolver lts-22.7 + --snapshot lts-22.7 --package base --package turtle -- @@ -262,7 +262,7 @@ {- stack exec ghci --install-ghc - --resolver lts-22.7 + --snapshot lts-22.7 --package turtle -} ~~~
doc/stack_yaml_vs_cabal_package_file.md view
@@ -50,14 +50,14 @@ * And a bunch more Stack configuration Often you will have a project that defines only one local Cabal package that you -are working on. If you need to specify an extra dependency, a source of -confusion can be why you need to specify it both in the `stack.yaml` file _and_ +are working on. If you need to specify a dependency, a source of confusion can +be why you need to specify it both in the `stack.yaml` file _and_ in the Cabal file. To explain, let's take a quick detour to talk about snapshots and how Stack resolves dependencies. ## Snapshots and resolvers -Stack follows a rule that says, for any projects, there is precisely one version +Stack follows a rule that says, for any project, there is precisely one version of each package available. Obviously, for many packages there are _many_ versions available in the world. But when resolving a `stack.yaml` file, Stack requires that you have chosen a specific version for each package available. @@ -152,7 +152,7 @@ `acme-missiles`, which is not in Stackage snapshots. If, however, you want to depend on a package already present in the snapshot you've selected, there's no need to add it explicitly to your `stack.yaml` file: it's already there -implicitly via the `resolver` setting. This is what you do the majority of the +implicitly via the `snapshot` setting. This is what you do the majority of the time, such as when you add `vector` or `mtl` as a `build-depends` value. ## Should I check-in automatically generated Cabal files?
doc/unpack_command.md view
@@ -14,11 +14,11 @@ In the case of packages from the package index, a target can be a package name only. In that case, by default: -* if Stack's `--resolver` option is not specified, the download is for the +* if Stack's `--snapshot` option is not specified, the download is for the most recent version of the package in the package index. Stack will first seek to update the index; and -* if Stack's `--resolver` option is specified, the download is for the version +* if Stack's `--snapshot` option is specified, the download is for the version of the package included directly in the specified snapshot. !!! note
doc/upgrade_command.md view
@@ -16,8 +16,13 @@ stack upgrade [--source-only] [--git] [--git-repo ARG] [--git-branch ARG] ~~~ -`stack upgrade` will get a new version of Stack. +`stack upgrade` will get a new version of Stack. It can also get a version +before the current version (downgrade). +!!! warning + + If you use GHCup to install Stack, use only GHCup to upgrade Stack. + By default: * the new version will be from an existing binary distribution. Pass the @@ -64,6 +69,13 @@ from the `master` branch of Stack's repository (pass the option `--git-branch <branch>` to specify a different branch and the option `--git-repo <repo_url>` to specify a different repository). + +!!! note + + An earlier version of Stack could be inconsistent with some of the current + contents of the Stack root. For further information about the contents of + the Stack root and configuring its location, see the documentation about the + [Stack root](stack_root.md). ## Examples
doc/yaml_configuration.md view
@@ -10,21 +10,23 @@ A Haskell package is an organised collection of Haskell code and related files. It is described by a Cabal file or a `package.yaml` file (which can be used to generate a Cabal file). The package description is itself part of - the package. Its file is located in the root directory of a local package. + the package. Its file is located in the root directory of a project package + or dependency located locally. A Stack project is a local directory that contains a Stack project-level - configuration file (`stack.yaml`). A project may relate to more than one - local package. A single-package project's directory will usually also be the - package's root directory. + configuration file (`stack.yaml`, by default). A project may relate to more + than one project package. A single-package project's directory will usually + also be the project package's root directory. ## YAML configuration Stack's YAML configuration options break down into [project-specific](#project-specific-configuration) options and -[non-project-specific](#non-project-specific-configuration) options. They are -configured at the project-level or globally. +[non-project-specific](#non-project-specific-configuration) options. The former +are configured at the project level. The latter are configured at the project +level or globally. -The **project-level** configuration file (`stack.yaml`) contains +The **project-level** configuration file (`stack.yaml`, by default) contains project-specific options and may contain non-project-specific options. However, non-project-specific options in the project-level configuration file in the `global-project` directory (see below) are ignored by Stack. @@ -39,11 +41,9 @@ [Stack root](stack_root.md). The **global** configuration file (`config.yaml`) contains only -non-project-specific options. - -Stack obtains global configuration from a file named `config.yaml`. The location -of this file depends on the operating system and whether Stack is configured to -use the XDG Base Directory Specification. +non-project-specific options. The location of this file depends on the operating +system and whether Stack is configured to use the XDG Base Directory +Specification. === "Unix-like" @@ -79,20 +79,30 @@ ## Project-specific configuration Project-specific configuration options are valid only in a project-level -configuration file (`stack.yaml`). +configuration file (`stack.yaml`, by default). -In your project-specific options, you specify both **which local packages** to -build and **which dependencies to use** when building these packages. Unlike the -user's local packages, these dependencies aren't built by default. They only get -built when needed. +Each of the Haskell packages to which a Stack project relates is either a +**project package** that is part of the project and located locally or a package +on which one or more of the project packages depends (directly or indirectly). +The latter is referred to as a **dependency** and it may be located locally or +elsewhere. -Shadowing semantics, described -[here](https://docs.haskellstack.org/en/v1.5.1/architecture/#shadowing), are -applied to your configuration. So, if you add a package to your `packages` list, -it will be used even if you're using a snapshot that specifies a particular -version. Similarly, `extra-deps` will shadow the version specified in the -snapshot. +!!! info + Project packages are built by default. Dependencies are only built when + needed. Building can target individual components of a project package. The + individual components of dependencies cannot be targeted. Test suite and + benchmark components of a project package can be built and run. The library + and executable components of a dependency, and only those components, are + built when the dependency is needed. + +In your project-specific options, you specify both **which project packages** to +build and **which dependencies to use** when building these packages. + +A dependency specified as an [extra-dep](#extra-deps) will shadow a package of +the same name specified in a [snapshot](#snapshot). A project package will +shadow a dependency of the same name. + ### snapshot Command line equivalent (takes precedence): @@ -100,10 +110,10 @@ [`--resolver`](global_flags.md#resolver-option) option The `snapshot` key specifies which snapshot is to be used for this project. A -snapshot defines a GHC version, a number of packages available for installation, -and various settings like build flags. It is also called a resolver since a -snapshot states how dependencies are resolved. There are currently four snapshot -types: +snapshot defines a GHC version, the package version of packages available for +installation, and various settings like build flags. It is also called a +resolver since a snapshot states how dependencies are resolved. There are +currently four snapshot types: * LTS Haskell snapshots, e.g. `snapshot: lts-22.7` * Stackage Nightly snapshots, e.g. `snapshot: nightly-2023-12-16` @@ -116,8 +126,9 @@ compiler version. See the [compiler-check](#compiler-check) option for some additional control over compiler version. -The `snapshot` key specifies a snapshot location. For further information, see -the [snapshot and package location](pantry.md) documentation. +A package version specified in a snapshot can be shadowed by an +[extra-dep](#extra-deps) of the same name or a [project package](#packages) of +the same name. ### resolver @@ -133,10 +144,11 @@ - . ~~~ -The `packages` key specifies a list of packages that are part of your local -project. These are specified via paths to local directories. A path is -considered relative to the directory containing the `stack.yaml` file. For -example, if the `stack.yaml` is located at `/dir1/dir2/stack.yaml`, and has: +The `packages` key specifies a list of the project packages that are part of +your project. These are specified via paths to local directories. A path is +considered relative to the directory containing the project-level configuration +file (`stack.yaml`, by default). For example, if the `stack.yaml` file is +located at `/dir1/dir2/stack.yaml`, and has: ~~~yaml packages: @@ -148,31 +160,36 @@ and `/dir1/dir2/dir3/my-other-package`". The `packages` key is optional. The default value, '`.`', means that the -project has a single package located in the current directory. +project has a single project package located in the current directory. -Each specified package directory must have a valid Cabal file or Hpack +A project package will shaddow a dependency of the same name. + +A package version specified in a snapshot can be shadowed by an +[extra-dep](#extra-deps) of the same name or a [project package](#packages) of +the same name. + +Each specified project package directory must have a valid Cabal file or Hpack `package.yaml` file present. Any subdirectories of the directory are not searched for Cabal files. A subdirectory has to be specified as an independent -item in the list of packages. +item in the list of project packages. -A project package is different from a dependency, both a snapshot dependency -(via the [`snapshot`](#snapshot) or [`resolver`](#resolver) key) and an -extra-deps dependency (via the [`extra-deps`](#extra-deps) key). For example: +A project package is different from a dependency (located locally or elsewhere) +specified as an [extra-dep](#extra-deps) or via a [snapshot](#snapshot). For +example: * a project package will be built by default by commanding [`stack build`](build_command.md) without specific targets. A dependency will - only be built if it is depended upon; and -* test suites and benchmarks may be run for a project package. They are never - run for a dependency. + only be built if it is needed; and +* test suites and benchmarks may be built and run for a project package. They + are never run for a dependency. ### extra-deps Default: `[]` The `extra-deps` key specifies a list of extra dependencies on top of what is -defined in the snapshot (specified by the [`snapshot`](#snapshot) or -[`resolver`](#resolver) key). A dependency may come from either a Pantry package -location or a local file path. +defined in the [snapshot](#snapshot). A dependency may come from either a Pantry +package location or a local file path. A Pantry package location is one or three different kinds of sources: @@ -240,13 +257,18 @@ package location (for example, a reference to a package on Hackage that omits the package's version) will be interpreted as a local file path. +An extra-dep will shadow a dependency specified in a [snapshot](#snapshot) of +the same name. An extra-dep can be shadowed by a [project package](#packages) of +the same name. + ### flags Default: `{}` -Command line equivalent (takes precedence): `stack build --flag` option +Command line equivalent (takes precedence): +[`stack build --flag`](build_command.md#-flag-option) option -Flags can be set for each package separately. For example: +Cabal flags can be set for each package separately. For example: ~~~yaml flags: @@ -254,9 +276,13 @@ flag-name: true ~~~ -If a specified flag is different than the one specified for a snapshot package, -then the snapshot package will automatically be promoted to be an extra-dep. +If a specified Cabal flag for a package included directly in a snapshot is +different to the Cabal flag specified for that package in the snapshot, then the +package will automatically be promoted to be an [extra-dep](#extra-deps). +In order to set a Cabal flag for a GHC boot package, the package must be +specified as an [extra-dep](#extra-deps). + ### drop-packages [:octicons-tag-24: 2.1.1](https://github.com/commercialhaskell/stack/releases/tag/v2.1.1) @@ -265,7 +291,7 @@ Packages which, when present in the snapshot specified in the [`snapshot`](#snapshot) or [`resolver`](#resolver) key, should not be included -in our package. This can be used for a few different purposes, e.g.: +in our project. This can be used for a few different purposes, e.g.: * Ensure that packages you don't want used in your project cannot be used in a `package.yaml` file (e.g., for license reasons) @@ -379,7 +405,7 @@ ## Non-project-specific configuration Non-project configuration options can be included in a project-level -configuration file (`stack.yaml`) or in global configuration files +configuration file (`stack.yaml`, by default) or in global configuration files (`config.yaml`). However, non-project-specific options in the project-level configuration file in the `global-project` directory are ignored by Stack. The options below are listed in alphabetic order. @@ -448,9 +474,9 @@ [`stack build --ghc-options`](build_command.md#-ghc-options-option) option Determines to which packages any GHC command line options specified on the -command line are applied. Possible values are: `everything` (all packages, local -or otherwise), `locals` (all local packages, targets or otherwise), and -`targets` (all local packages that are targets). +command line are applied. Possible values are: `everything` (all packages, +project packages or otherwise), `locals` (all project packages, targets or +otherwise), and `targets` (all project packages that are targets). !!! note @@ -471,8 +497,8 @@ Determines to which packages all and any `--PROG-option` command line options specified on the command line are applied. Possible values are: `everything` -(all packages, local or otherwise), `locals` (all local packages, targets or -otherwise), and `targets` (all local packages that are targets). +(all packages, project packages or otherwise), `locals` (all project packages, +targets or otherwise), and `targets` (all project packages that are targets). !!! note @@ -658,8 +684,8 @@ Overrides the compiler version in the snapshot. Note that the `compiler-check` flag also applies to the version numbers. This uses the same syntax as compiler -resolvers like `ghc-9.6.3`. This can be used to override the -compiler for a Stackage snapshot, like this: +snapshots like `ghc-9.6.3`. This can be used to override the compiler for a +Stackage snapshot, like this: ~~~yaml snapshot: lts-22.7 @@ -726,9 +752,9 @@ The resolution is: (1) to specify an alternative snapshot (one that specifies a sufficiently recent version of GHC) on the command line, using - Stack's option `--resolver <snapshot>`. Stack will use that snapshot when + Stack's option `--snapshot <snapshot>`. Stack will use that snapshot when running GHC's `configure` script; and (2) to set the contents of the `STACK` - environment variable to be `stack --resolver <snapshot>`. Hadrian's + environment variable to be `stack --snapshot <snapshot>`. Hadrian's `build-stack` script wil refer to that environment variable for the Stack command it uses. @@ -866,10 +892,10 @@ `configure-options` can specify Cabal (the library) options (including `--PROG-option` or `--PROG-options` options) for the configure step of the Cabal -build process for a named package, all local packages that are targets (using -the `$targets` key), all local packages (targets or otherwise) (using the -`$locals` key), or all packages (local or otherwise) (using the `$everything` -key). +build process for a named package, all project packages that are targets (using +the `$targets` key), all project packages (targets or otherwise) (using the +`$locals` key), or all packages (project packages or otherwise) (using the +`$everything` key). ~~~yaml configure-options: @@ -1034,13 +1060,13 @@ Related command line (takes precedence): [`stack build --ghc-options`](build_command.md#-ghc-options-option) option -Augment and, if applicable, override any GHC command line options specified in -Cabal files (including those created from `package.yaml` files). +GHC command line options can be specified for a package in its Cabal file +(including one created from a `package.yaml` file). This option augments and, if applicable (see below), overrides any such GHC command line options. `ghc-options` can specify GHC command line options for a named package, all -local packages that are targets (using the `$targets` key), all local packages -(targets or otherwise) (using the `$locals` key), or all packages (local or -otherwise) (using the `$everything` key). +project packages that are targets (using the `$targets` key), all project +packages (targets or otherwise) (using the `$locals` key), or all packages +(project packages or otherwise) (using the `$everything` key). ~~~yaml ghc-options: @@ -1058,9 +1084,9 @@ YAML configuration files. Since Stack 1.6.1, setting a GHC options for a specific package will -automatically promote it to a local package (much like setting a custom package -flag). However, setting options via `$everything` on all flags will not do so -(see +automatically promote it to a project package (much like setting a custom +package flag). However, setting options via `$everything` on all flags will not +do so (see [GitHub discussion](https://github.com/commercialhaskell/stack/issues/849#issuecomment-320892095) for reasoning). This can lead to unpredictable behavior by affecting your snapshot packages. @@ -1681,15 +1707,20 @@ Default: `false` -Command line equivalent (takes precedence): `--[no-]skip-msys` flag +Command line equivalent (takes precedence): +[`--[no-]skip-msys`](global_flags.md#-no-skip-msys-option) flag -Skips checking for and installing MSYS2 when stack is Setting up the -environment. This usually doesn't make sense in project-level configurations, -just in `config.yaml`. +Skips checking for the Stack-supplied MSYS2 (and installing that MSYS2, if it is +not installed) when Stack is setting up the environment. ~~~yaml skip-msys: true ~~~ + +!!! note + + Usually, the use of this option does not make sense in project-level + configuration and it is used only in global configuration. ### snapshot-location-base
src/Stack/Build/ExecuteEnv.hs view
@@ -230,12 +230,6 @@ , toFilePath setupShimHs , "-o" , toFilePath tmpOutputPath - -- See https://github.com/commercialhaskell/stack/issues/6267. As - -- corrupt *.hi and/or *.o files can be problematic, we aim to - -- to leave none behind. This can be dropped when Stack drops - -- support for the problematic versions of GHC. - , "-no-keep-hi-files" - , "-no-keep-o-files" ] compilerPath <- getCompilerPath withWorkingDir (toFilePath tmpdir) $
src/Stack/Build/ExecutePackage.hs view
@@ -596,20 +596,21 @@ fulfillHaddockExpectations pname mcurator $ \keep -> do let args = concat - ( if isHaddockForHackage - then - [ [ "--for-hackage" ] ] - else - [ [ "--html" - , "--hoogle" - , "--html-location=../$pkg-$version/" - ] - , [ "--haddock-option=--hyperlinked-source" - | ee.buildOpts.haddockHyperlinkSource - ] - , [ "--internal" | ee.buildOpts.haddockInternal ] - , quickjump - ] + ( ( if isHaddockForHackage + then + [ [ "--for-hackage" ] ] + else + [ [ "--html" + , "--hoogle" + , "--html-location=../$pkg-$version/" + ] + , [ "--haddock-option=--hyperlinked-source" + | ee.buildOpts.haddockHyperlinkSource + ] + , [ "--internal" | ee.buildOpts.haddockInternal ] + , quickjump + ] + ) <> [ [ "--haddock-option=" <> opt | opt <- ee.buildOpts.haddockOpts.additionalArgs ]
src/Stack/Exec.hs view
@@ -15,13 +15,14 @@ import qualified Data.Map.Strict as Map import qualified Data.Set as Set import qualified Data.Text as T +import Distribution.Types.PackageName ( unPackageName ) import RIO.NonEmpty ( head, nonEmpty ) import RIO.Process ( exec ) import Stack.Build ( build ) -import Stack.Build.Target ( NeedTargets (..) ) +import Stack.Build.Target + ( NeedTargets (..), RawTarget (..), parseRawTarget ) import Stack.GhcPkg ( findGhcPkgField ) import Stack.Setup ( withNewLocalBuildTargets ) -import Stack.Types.NamedComponent ( NamedComponent (..), isCExe ) import Stack.Prelude import Stack.Runners ( ShouldReexec (..), withConfig, withEnvConfig ) import Stack.Types.BuildConfig @@ -33,6 +34,7 @@ import Stack.Types.Config ( Config (..), HasConfig (..) ) import Stack.Types.EnvConfig ( EnvConfig ) import Stack.Types.EnvSettings ( EnvSettings (..) ) +import Stack.Types.NamedComponent ( NamedComponent (..), isCExe ) import Stack.Types.Runner ( Runner ) import Stack.Types.SourceMap ( SMWanted (..), ppComponents ) import System.Directory ( withCurrentDirectory ) @@ -58,6 +60,7 @@ = PackageIdNotFoundBug !String | ExecutableToRunNotFound | NoPackageIdReportedBug + | InvalidExecTargets ![Text] deriving (Show, Typeable) instance Pretty ExecPrettyException where @@ -72,6 +75,20 @@ <> flow "No executables found." pretty NoPackageIdReportedBug = bugPrettyReport "S-8600" $ flow "execCmd: findGhcPkgField returned Just \"\"." + pretty (InvalidExecTargets targets) = + "[S-7371]" + <> line + <> fillSep + [ flow "The following are invalid" + , style Shell "--package" + , "values for" + , style Shell (flow "stack ghc") <> "," + , style Shell (flow "stack runghc") <> "," + , "or" + , style Shell (flow "stack runhaskell") <> ":" + ] + <> line + <> bulletedList (map (style Target . string . T.unpack) targets ) instance Exception ExecPrettyException @@ -99,12 +116,17 @@ } deriving Show +-- Type representing valid targets for --package option. +data ExecTarget = ExecTarget PackageName (Maybe Version) + -- | The function underlying Stack's @exec@, @ghc@, @run@, @runghc@ and -- @runhaskell@ commands. Execute a command. execCmd :: ExecOpts -> RIO Runner () execCmd opts = withConfig YesReexec $ withEnvConfig AllowNoTargets boptsCLI $ do - unless (null targets) $ build Nothing + let (errs, execTargets) = partitionEithers $ map fromTarget targets + unless (null errs) $ prettyThrowM $ InvalidExecTargets errs + unless (null execTargets) $ build Nothing config <- view configL menv <- liftIO $ config.processContextSettings eo.envSettings @@ -116,18 +138,32 @@ (cmd, args) <- case (opts.cmd, argsWithRts opts.args) of (ExecCmd cmd, args) -> pure (cmd, args) (ExecRun, args) -> getRunCmd args - (ExecGhc, args) -> getGhcCmd eo.packages args - (ExecRunGhc, args) -> getRunGhcCmd eo.packages args + (ExecGhc, args) -> getGhcCmd execTargets args + (ExecRunGhc, args) -> getRunGhcCmd execTargets args runWithPath eo.cwd $ exec cmd args where eo = opts.extra - targets = concatMap words eo.packages - boptsCLI = defaultBuildOptsCLI { targetsCLI = map T.pack targets } + targets = concatMap (T.words . T.pack) eo.packages + boptsCLI = defaultBuildOptsCLI { targetsCLI = targets } + fromTarget :: Text -> Either Text ExecTarget + fromTarget target = + case parseRawTarget target >>= toExecTarget of + Nothing -> Left target + Just execTarget -> Right execTarget + + toExecTarget :: RawTarget -> Maybe ExecTarget + toExecTarget (RTPackageComponent _ _) = Nothing + toExecTarget (RTComponent _) = Nothing + toExecTarget (RTPackage name) = Just $ ExecTarget name Nothing + toExecTarget (RTPackageIdentifier (PackageIdentifier name pkgId)) = + Just $ ExecTarget name (Just pkgId) + -- return the package-id of the first package in GHC_PACKAGE_PATH - getPkgId name = do + getPkgId (ExecTarget pkgName _) = do + let name = unPackageName pkgName pkg <- getGhcPkgExe mId <- findGhcPkgField pkg [] name "id" case mId of
src/Stack/Options/ExecParser.hs view
@@ -67,8 +67,9 @@ eoPackagesParser :: Parser [String] eoPackagesParser = many (strOption ( long "package" - <> metavar "PACKAGE" - <> help "Add a package (can be specified multiple times)." + <> metavar "PACKAGE(S)" + <> help "Add package(s) as a list of names or identifiers separated by \ + \spaces (can be specified multiple times)." )) eoRtsOptionsParser :: Parser [String]
src/Stack/Options/PathParser.hs view
@@ -7,15 +7,22 @@ import qualified Data.Text as T import Options.Applicative ( Parser, flag, help, long ) -import Stack.Path ( paths ) +import Stack.Path + ( pathsFromConfig, pathsFromEnvConfig, pathsFromRunner ) import Stack.Prelude -- | Parse command line arguments for Stack's @path@ command. pathParser :: Parser [Text] pathParser = mapMaybeA - ( \(desc, name, _) -> flag Nothing (Just name) + ( \(desc, name) -> flag Nothing (Just name) ( long (T.unpack name) <> help desc ) ) paths + where + toDescName (desc, name, _) = (desc, name) + paths = + pathsFromRunner + : map toDescName pathsFromConfig + <> map toDescName pathsFromEnvConfig
src/Stack/Path.hs view
@@ -6,9 +6,11 @@ -- | Types and functions related to Stack's @path@ command. module Stack.Path - ( PathInfo + ( EnvConfigPathInfo , path - , paths + , pathsFromRunner + , pathsFromConfig + , pathsFromEnvConfig ) where import Data.List ( intercalate ) @@ -35,8 +37,7 @@ import Stack.Types.CompilerPaths ( CompilerPaths (..), HasCompiler (..), getCompilerPath ) import Stack.Types.Config - ( Config (..), HasConfig (..), stackGlobalConfigL, stackRootL - ) + ( Config (..), HasConfig (..), stackGlobalConfigL ) import Stack.Types.EnvConfig ( EnvConfig, HasEnvConfig (..), bindirCompilerTools , hpcReportDir, installationRootDeps, installationRootLocal @@ -54,48 +55,79 @@ -- | Print out useful path information in a human-readable format (and support -- others later). path :: [Text] -> RIO Runner () --- Distinguish a request for only the Stack root, as such a request does not --- require 'withDefaultEnvConfig'. -path [key] | key == stackRootOptionName' = do - clArgs <- view $ globalOptsL . to (.configMonoid) - liftIO $ do - (_, stackRoot, _) <- determineStackRootAndOwnership clArgs - T.putStrLn $ T.pack $ toFilePathNoTrailingSep stackRoot path keys = do let -- filter the chosen paths in flags (keys), or show all of them if no -- specific paths chosen. - goodPaths = filter - ( \(_, key, _) -> null keys || elem key keys ) - paths - singlePath = length goodPaths == 1 - toEither (_, k, UseHaddocks p) = Left (k, p) - toEither (_, k, WithoutHaddocks p) = Right (k, p) - (with, without) = partitionEithers $ map toEither goodPaths - runHaddock True $ printKeys with singlePath - runHaddock False $ printKeys without singlePath + filterKeys (_, key, _) = null keys || elem key keys + goodPathsFromRunner = null keys || elem stackRootOptionName' keys + goodPathsFromConfig = filter filterKeys pathsFromConfig + goodPathsFromEnvConfig = filter filterKeys pathsFromEnvConfig + toKeyPath (_, key, p) = (key, p) + goodPathsFromConfig' = map toKeyPath goodPathsFromConfig + singlePath = (if goodPathsFromRunner then 1 else 0) + + length goodPathsFromConfig + length goodPathsFromEnvConfig == 1 + toEither (_, k, UseHaddocks a) = Left (k, a) + toEither (_, k, WithoutHaddocks a) = Right (k, a) + (with, without) = partitionEithers $ map toEither goodPathsFromEnvConfig + when goodPathsFromRunner $ printKeysWithRunner singlePath + unless (null goodPathsFromConfig') $ + runHaddockWithConfig $ printKeysWithConfig goodPathsFromConfig' singlePath + unless (null without) $ + runHaddockWithEnvConfig False $ printKeysWithEnvConfig without singlePath + unless (null with) $ + runHaddockWithEnvConfig True $ printKeysWithEnvConfig with singlePath -printKeys :: +printKeysWithRunner :: + Bool + -> RIO Runner () +printKeysWithRunner single = do + clArgs <- view $ globalOptsL . to (.configMonoid) + liftIO $ do + (_, stackRoot, _) <- determineStackRootAndOwnership clArgs + let prefix = if single then "" else stackRootOptionName' <> ": " + T.putStrLn $ prefix <> T.pack (toFilePathNoTrailingSep stackRoot) + +printKeysWithConfig :: + HasConfig env + => [(Text, Config -> Text)] + -> Bool + -> RIO env () +printKeysWithConfig extractors single = + view configL >>= printKeys extractors single + +printKeysWithEnvConfig :: HasEnvConfig env - => [(Text, PathInfo -> Text)] + => [(Text, EnvConfigPathInfo -> Text)] -> Bool -> RIO env () -printKeys extractors single = do - pathInfo <- fillPathInfo +printKeysWithEnvConfig extractors single = + fillEnvConfigPathInfo >>= printKeys extractors single + +printKeys :: + [(Text, info -> Text)] + -> Bool + -> info + -> RIO env () +printKeys extractors single info = do liftIO $ forM_ extractors $ \(key, extractPath) -> do let prefix = if single then "" else key <> ": " - T.putStrLn $ prefix <> extractPath pathInfo + T.putStrLn $ prefix <> extractPath info -runHaddock :: Bool -> RIO EnvConfig () -> RIO Runner () -runHaddock x action = local modifyConfig $ - withConfig YesReexec $ - withDefaultEnvConfig action +runHaddockWithEnvConfig :: Bool -> RIO EnvConfig () -> RIO Runner () +runHaddockWithEnvConfig x action = runHaddock x (withDefaultEnvConfig action) + +runHaddockWithConfig :: RIO Config () -> RIO Runner () +runHaddockWithConfig = runHaddock False + +runHaddock :: Bool -> RIO Config () -> RIO Runner () +runHaddock x action = local modifyConfig $ withConfig YesReexec action where modifyConfig = set (globalOptsL . globalOptsBuildOptsMonoidL . buildOptsMonoidHaddockL) (Just x) -fillPathInfo :: HasEnvConfig env => RIO env PathInfo -fillPathInfo = do +fillEnvConfigPathInfo :: HasEnvConfig env => RIO env EnvConfigPathInfo +fillEnvConfigPathInfo = do -- We must use a BuildConfig from an EnvConfig to ensure that it contains the -- full environment info including GHC paths etc. buildConfig <- view $ envConfigL . buildConfigL @@ -115,7 +147,7 @@ distDir <- distRelativeDir hpcDir <- hpcReportDir compiler <- getCompilerPath - pure PathInfo + pure EnvConfigPathInfo { buildConfig , snapDb , localDb @@ -130,8 +162,7 @@ , compiler } --- | Type representing information passed to all the path printers. -data PathInfo = PathInfo +data EnvConfigPathInfo = EnvConfigPathInfo { buildConfig :: !BuildConfig , snapDb :: !(Path Abs Dir) , localDb :: !(Path Abs Dir) @@ -146,40 +177,40 @@ , compiler :: !(Path Abs File) } -instance HasPlatform PathInfo where +instance HasPlatform EnvConfigPathInfo where platformL = configL . platformL {-# INLINE platformL #-} platformVariantL = configL . platformVariantL {-# INLINE platformVariantL #-} -instance HasLogFunc PathInfo where +instance HasLogFunc EnvConfigPathInfo where logFuncL = configL . logFuncL -instance HasRunner PathInfo where +instance HasRunner EnvConfigPathInfo where runnerL = configL . runnerL -instance HasStylesUpdate PathInfo where +instance HasStylesUpdate EnvConfigPathInfo where stylesUpdateL = runnerL . stylesUpdateL -instance HasTerm PathInfo where +instance HasTerm EnvConfigPathInfo where useColorL = runnerL . useColorL termWidthL = runnerL . termWidthL -instance HasGHCVariant PathInfo where +instance HasGHCVariant EnvConfigPathInfo where ghcVariantL = configL . ghcVariantL {-# INLINE ghcVariantL #-} -instance HasConfig PathInfo where +instance HasConfig EnvConfigPathInfo where configL = buildConfigL . lens (.config) (\x y -> x { config = y }) {-# INLINE configL #-} -instance HasPantryConfig PathInfo where +instance HasPantryConfig EnvConfigPathInfo where pantryConfigL = configL . pantryConfigL -instance HasProcessContext PathInfo where +instance HasProcessContext EnvConfigPathInfo where processContextL = configL . processContextL -instance HasBuildConfig PathInfo where +instance HasBuildConfig EnvConfigPathInfo where buildConfigL = lens (.buildConfig) (\x y -> x { buildConfig = y }) . buildConfigL @@ -187,68 +218,97 @@ = UseHaddocks a | WithoutHaddocks a --- | The paths of interest to a user. The first tuple string is used for a --- description that the optparse flag uses, and the second string as a --- machine-readable key and also for @--foo@ flags. The user can choose a --- specific path to list like @--stack-root@. But really it's mainly for the --- documentation aspect. +-- | The paths of interest to a user which do require a 'Config' or 'EnvConfig'. +-- The first tuple string is used for a description that the optparse flag uses, +-- and the second string as a machine-readable key and also for @--foo@ flags. +-- The user can choose a specific path to list like @--stack-root@. But really +-- it's mainly for the documentation aspect. +pathsFromRunner :: (String, Text) +pathsFromRunner = ("Global Stack root directory", stackRootOptionName') + +-- | The paths of interest to a user which do require an 'EnvConfig'. The first +-- tuple string is used for a description that the optparse flag uses, and the +-- second string as a machine-readable key and also for @--foo@ flags. The user +-- can choose a specific path to list like @--stack-root@. But really it's +-- mainly for the documentation aspect. -- --- When printing output we generate @PathInfo@ and pass it to the function to --- generate an appropriate string. Trailing slashes are removed, see #506. -paths :: [(String, Text, UseHaddocks (PathInfo -> Text))] -paths = - [ ( "Global Stack root directory" - , stackRootOptionName' - , WithoutHaddocks $ - view (stackRootL . to toFilePathNoTrailingSep . to T.pack)) - , ( "Global Stack configuration file" +-- When printing output we generate @Config@ and pass it to the function +-- to generate an appropriate string. Trailing slashes are removed, see #506. +pathsFromConfig :: [(String, Text, Config -> Text)] +pathsFromConfig = + [ ( "Global Stack configuration file" , T.pack stackGlobalConfigOptionName - , WithoutHaddocks $ view (stackGlobalConfigL . to toFilePath . to T.pack)) - , ( "Project root (derived from stack.yaml file)" + , view (stackGlobalConfigL . to toFilePath . to T.pack) + ) + , ( "Install location for GHC and other core tools (see 'stack ls tools' command)" + , "programs" + , view (configL . to (.localPrograms) . to toFilePathNoTrailingSep . to T.pack) + ) + , ( "Directory where Stack installs executables (e.g. ~/.local/bin (Unix-like OSs) or %APPDATA%\\local\\bin (Windows))" + , "local-bin" + , view $ configL . to (.localBin) . to toFilePathNoTrailingSep . to T.pack + ) + ] + +-- | The paths of interest to a user which require a 'EnvConfig'. The first +-- tuple string is used for a description that the optparse flag uses, and the +-- second string as a machine-readable key and also for @--foo@ flags. The user +-- can choose a specific path to list like @--project-root@. But really it's +-- mainly for the documentation aspect. +-- +-- When printing output we generate @EnvConfigPathInfo@ and pass it to the +-- function to generate an appropriate string. Trailing slashes are removed, see +-- #506. +pathsFromEnvConfig :: [(String, Text, UseHaddocks (EnvConfigPathInfo -> Text))] +pathsFromEnvConfig = + [ ( "Project root (derived from stack.yaml file)" , "project-root" , WithoutHaddocks $ - view (projectRootL . to toFilePathNoTrailingSep . to T.pack)) + view (projectRootL . to toFilePathNoTrailingSep . to T.pack) + ) , ( "Configuration location (where the stack.yaml file is)" , "config-location" - , WithoutHaddocks $ view (stackYamlL . to toFilePath . to T.pack)) + , WithoutHaddocks $ view (stackYamlL . to toFilePath . to T.pack) + ) , ( "PATH environment variable" , "bin-path" , WithoutHaddocks $ - T.pack . intercalate [FP.searchPathSeparator] . view exeSearchPathL) - , ( "Install location for GHC and other core tools (see 'stack ls tools' command)" - , "programs" - , WithoutHaddocks $ - view (configL . to (.localPrograms) . to toFilePathNoTrailingSep . to T.pack)) + T.pack . intercalate [FP.searchPathSeparator] . view exeSearchPathL + ) , ( "Compiler binary (e.g. ghc)" , "compiler-exe" - , WithoutHaddocks $ T.pack . toFilePath . (.compiler) ) + , WithoutHaddocks $ T.pack . toFilePath . (.compiler) + ) , ( "Directory containing the compiler binary (e.g. ghc)" , "compiler-bin" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . parent . (.compiler) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . parent . (.compiler) + ) , ( "Directory containing binaries specific to a particular compiler" , "compiler-tools-bin" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.toolsDir) ) - , ( "Directory where Stack installs executables (e.g. ~/.local/bin (Unix-like OSs) or %APPDATA%\\local\\bin (Windows))" - , "local-bin" - , WithoutHaddocks $ - view $ configL . to (.localBin) . to toFilePathNoTrailingSep . to T.pack) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.toolsDir) + ) , ( "Extra include directories" , "extra-include-dirs" , WithoutHaddocks $ - T.intercalate ", " . map T.pack . (.extraIncludeDirs) . view configL ) + T.intercalate ", " . map T.pack . (.extraIncludeDirs) . view configL + ) , ( "Extra library directories" , "extra-library-dirs" , WithoutHaddocks $ - T.intercalate ", " . map T.pack . (.extraLibDirs) . view configL ) + T.intercalate ", " . map T.pack . (.extraLibDirs) . view configL + ) , ( "Snapshot package database" , "snapshot-pkg-db" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.snapDb) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.snapDb) + ) , ( "Local project package database" , "local-pkg-db" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.localDb) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.localDb) + ) , ( "Global package database" , "global-pkg-db" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.globalDb) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.globalDb) + ) , ( "GHC_PACKAGE_PATH environment variable" , "ghc-package-path" , WithoutHaddocks $ @@ -261,11 +321,12 @@ ) , ( "Snapshot installation root" , "snapshot-install-root" - , WithoutHaddocks $ - T.pack . toFilePathNoTrailingSep . (.snapRoot) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.snapRoot) + ) , ( "Local project installation root" , "local-install-root" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.localRoot) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.localRoot) + ) , ( "Snapshot documentation root" , "snapshot-doc-root" , UseHaddocks $ @@ -278,13 +339,16 @@ ) , ( "Local project documentation root" , "local-hoogle-root" - , UseHaddocks $ T.pack . toFilePathNoTrailingSep . (.hoogleRoot)) + , UseHaddocks $ T.pack . toFilePathNoTrailingSep . (.hoogleRoot) + ) , ( "Dist work directory, relative to package directory" , "dist-dir" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.distDir) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.distDir) + ) , ( "Where HPC reports and tix files are stored" , "local-hpc-root" - , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.hpcDir) ) + , WithoutHaddocks $ T.pack . toFilePathNoTrailingSep . (.hpcDir) + ) ] -- | 'Text' equivalent of 'stackRootOptionName'.
stack.cabal view
@@ -1,6 +1,6 @@ cabal-version: 2.0 name: stack-version: 2.15.1+version: 2.15.3 license: BSD3 license-file: LICENSE maintainer: manny@fpcomplete.com@@ -404,7 +404,7 @@ neat-interpolation >=0.5.1.4, open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0,- pantry >=0.9.3.1,+ pantry >=0.9.3.2, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,@@ -531,7 +531,7 @@ neat-interpolation >=0.5.1.4, open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0,- pantry >=0.9.3.1,+ pantry >=0.9.3.2, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,@@ -640,7 +640,7 @@ open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0, optparse-generic >=1.5.2,- pantry >=0.9.3.1,+ pantry >=0.9.3.2, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,@@ -764,7 +764,7 @@ neat-interpolation >=0.5.1.4, open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0,- pantry >=0.9.3.1,+ pantry >=0.9.3.2, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,
stack.yaml view
@@ -4,6 +4,7 @@ # Cabal is pruned because process is a GHC boot package, and has to be specified # again. - Cabal-3.10.1.0@sha256:6d11adf7847d9734e7b02785ff831b5a0d11536bfbcefd6634b2b08411c63c94,12316 +- pantry-0.9.3.2@sha256:336373d8cbb10505ff16ac6e35cb9d8a7f45293a908de1c00f55c133ee7dde86,7511 # GHC 9.6.4 comes with process-1.6.17.0, which can segfault on macOS. - process-1.6.18.0@sha256:cd0a3e0376b5a8525983d3131a31e52f9ffefc278ce635eec45a9d3987b8be3e,3025