Update resolvers, migrate to crypton #109
Conversation
1. Use stack-all, and follow its major-only naming convention There's no reason to care about minor, and keeping the file names stable if/when it changes means we don't have to change required statuses on GitHub (which are named after the matrix values). 2. Remove all lockfiles except `stack.yaml.lock` These lockfiles are important for reproducibility, which, if it matters at all for this project, only matters for the `stack.yaml` build. Builds of other resolvers almost-always only occur on CI. And when they occur locally, they may or may not generate/update lock files (they won't if using `stack-all`). To avoid confusion from that inconsistency, we'll git-ignore them so their [non]presence becomes a local concern.
We were re-specifying the defaults already[^1], which was fine until 0.4.0 added a new member of a type that is not easily constructed (`Supported`). In fact, the library seems to want you to construct it via the `Default` instance (which we don't normally prefer), so we might as well do the whole record like that to avoid any CPP on the specific field. [^1]: https://hackage.haskell.org/package/crypton-connection-0.4.3/docs/src/Network.Connection.Types.html#line-95
Is the general rule here that Stack lockfiles should only be checked in for configs that build some application artifact that we want to use? |
|
It seems an irksome result that we now have a pair of CI jobs |
I think that's the most important use-case for reproducibility, yes. |
Be the symlink you want to see in the world |
|
If stack.yaml is a symlink to stack-ltsXX.yaml, will |
|
|
Reconfigure stack.yaml files
e178e82
Use stack-all, and follow its major-only naming convention
There's no reason to care about minor, and keeping the file names
stable if/when it changes means we don't have to change required
statuses on GitHub (which are named after the matrix values).
Remove all lockfiles except
stack.yaml.lockThese lockfiles are important for reproducibility, which, if it
matters at all for this project, only matters for the
stack.yamlbuild. Builds of other resolvers almost-always only occur on CI. And
when they occur locally, they may or may not generate/update lock
files (they won't if using
stack-all). To avoid confusion from thatinconsistency, we'll git-ignore them so their [non]presence becomes a
local concern.
Rev actions, use generate-matrix
950179a
Use Default TLSSettings, support crypton-connection >= 0.4.0
44c3e88
We were re-specifying the defaults already1, which was fine until
0.4.0 added a new member of a type that is not easily constructed
(
Supported). In fact, the library seems to want you to construct itvia the
Defaultinstance (which we don't normally prefer), so we mightas well do the whole record like that to avoid any CPP on the specific
field.
Ignore Functor law
70bcb31
Remove old Brittany pragmas
cb806a0
Add Restyled workflow
83ac7b6
Switch cryptonite with crypton
46c5942
commercialhaskell/stackage#7474
Footnotes
https://hackage.haskell.org/package/crypton-connection-0.4.3/docs/src/Network.Connection.Types.html#line-95 ↩