You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+61Lines changed: 61 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -38,3 +38,64 @@ out=$(pwd) genericBuild
38
38
```
39
39
40
40
Build logs are written to stdout and artifacts written to the current directory.
41
+
42
+
## Releasing packages to CHaP
43
+
44
+
When new versions of the packages are released, they should be included in [CHaP](https://github.com/input-output-hk/cardano-haskell-packages).
45
+
See the CHaP README for [instructions](https://github.com/input-output-hk/cardano-haskell-packages#-from-github).
46
+
47
+
## Updating dependencies
48
+
49
+
Our Haskell packages come from two package repositories:
50
+
- Hackage
51
+
-[CHaP](https://github.com/input-output-hk/cardano-haskell-packages) (which is essentially another Hackage)
52
+
53
+
The "index state" of each repository is pinned to a particular time in
54
+
`cabal.project`. This tells Cabal to treat the repository as if it was
55
+
the specified time, ensuring reproducibility. If you want to use a package
56
+
version from repository X which was added after the pinned index state
57
+
time, you need to bump the index state for X. This is not a big deal,
58
+
since all it does is change what packages `cabal` considers to be available
59
+
when doing solving, but it will change what package versions cabal picks
60
+
for the plan, and so will likely result in significant recompilation, and
61
+
potentially some breakage. That typically just means that we need to fix
62
+
the breakage (increasing the lower-bound on the problematic package if fix
63
+
is not backward compatible), or delay that work and instead decrease the
64
+
upper-bound on the problematic package for now.
65
+
66
+
Note that `cabal`'s own persistent state includes which index states it is
67
+
aware of, so when you bump the pinned index state you may need to
68
+
call `cabal update` in order for `cabal` to be happy.
69
+
70
+
The Nix code which builds our packages also needs some information relating
71
+
to the index-state. This information needs to be new enough to include
72
+
the index-state specified in `cabal.project`. The information is represented
73
+
by inputs managed by `niv`:
74
+
You can update these by running:
75
+
-`niv update hackage.nix` for Hackage
76
+
-`niv update CHaP` for CHaP
77
+
78
+
If you fail to do this you may get an error like this from Nix:
79
+
```
80
+
error: Unknown index-state 2021-08-08T00:00:00Z, the latest index-state I know about is 2021-08-06T00:00:00Z. You may need to update to a newer hackage.nix.
81
+
```
82
+
83
+
### Use of `source-repository-package`s
84
+
85
+
We *can* use Cabal's `source-repository-package` mechanism to pull in
86
+
un-released package versions. This can be useful when debugging/developing
87
+
across different repositories. However, we should not release our packages
88
+
to CHaP while we depend on a `source-repository-package` since downstream
89
+
consumers would not be able to build such package.
90
+
91
+
If we are stuck in a situation where we need a long-running fork of a
92
+
package, we should release it to CHaP instead (see the
![iohk-bors[bot]](https://avatars.githubusercontent.com/in/17473?v=4&size=40){kind=avatar}
0 commit comments