1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
<div class="hidden-warning"><a href="https://docs.haskellstack.org/"><img src="https://cdn.jsdelivr.net/gh/commercialhaskell/stack/doc/img/hidden-warning.svg"></a></div>
## Snapshot specification
[:octicons-tag-24: 2.1.1](https://github.com/commercialhaskell/stack/releases/tag/v2.1.1)
Snapshots provide a list of packages to use, along with flags, GHC options, and
a few other settings. Snapshots may extend any other snapshot that can be
specified in a [`snapshot`](yaml_configuration.md#snapshot) or
[`resolver`](yaml_configuration.md#resolver) key. The packages specified follow
the same syntax for dependencies in Stack's project-level configuration files.
Unlike the `extra-deps` key, however, no support for local directories is
available in snapshots to ensure reproducibility.
!!! info
Stack uses the [Pantry](https://hackage.haskell.org/package/pantry) library
for snapshot specification.
~~~yaml
snapshot: lts-22.21 # Inherits GHC version and package set
compiler: ghc-9.6.4 # Overwrites GHC version in the snapshot, optional
# Additional packages, follows extra-deps syntax
packages:
- unordered-containers-0.2.7.1
- hashable-1.2.4.0
- text-1.2.2.1
# Packages from the parent snapshot to ignore
drop-packages:
- wai-extra
# Packages which should be hidden
hidden:
wai: true
warp: false
# Set GHC options for specific packages
ghc-options:
warp:
- -O2
# Override flags, can also override flags in the parent snapshot
flags:
unordered-containers:
debug: true
~~~
If you put this in a `snapshot.yaml` file in the same directory as your project,
you can now use the snapshot like this:
~~~yaml
snapshot: snapshot.yaml
~~~
This is an example of a custom snapshot stored in the filesystem. They are
assumed to be mutable, so you are free to modify it. We detect that the snapshot
has changed by hashing the contents of the involved files, and using it to
identify the snapshot internally. It is often reasonably efficient to modify a
custom snapshot, due to Stack sharing snapshot packages whenever possible.
### Overriding the compiler
The following snapshot specification will be identical to `lts-22.21`, but
instead use `ghc-9.6.4` instead of `ghc-9.6.5`:
~~~yaml
snapshot: lts-22.21
compiler: ghc-9.6.4
~~~
### Dropping packages
The following snapshot specification will be identical to `lts-22.21`, but
without the `text` package in our snapshot. Removing this package will cause all
the packages that depend on `text` to be unbuildable, but they will still be
present in the snapshot.
~~~yaml
snapshot: lts-22.21
drop-packages:
- text
~~~
### Hiding packages
The following snapshot specification will be identical to `lts-22.21`, but the
`text` package will be hidden when registering. This will affect, for example,
the import parser in the script command.
~~~yaml
snapshot: lts-22.21
hidden:
- text
~~~
### Specifying GHC options
In order to specify GHC options for a package, you use the same syntax as the
[ghc-options](yaml_configuration.md#ghc-options) key for build configuration.
The following snapshot specification will be identical to `lts-22.21`, but
provides `-O1` as a ghc-option for `text`:
~~~yaml
snapshot: lts-22.21
packages:
- text-2.0.2
ghc-options:
text: -O1
~~~
This works somewhat differently than the stack.yaml `ghc-options` field, in that
options can only be specified for packages that are mentioned in the custom
snapshot's `packages` list. It sets the ghc-options, rather than extending those
specified in the snapshot being extended.
Another difference is that the `*` entry for `ghc-options` applies to all
packages in the `packages` list, rather than all packages in the snapshot.
### Specifying Cabal flags
In order to specify Cabal flags for a package, you use the same syntax as the
[flags](yaml_configuration.md#flags) key for build configuration. The
following snapshot specification will be identical to `lts-22.21`, but
it enables the `developer` Cabal flag:
~~~yaml
snapshot: lts-22.21
packages:
- text-2.0.2
flags:
text:
developer: true
~~~
|
