Moritz Angermann
Moritz Angermann
That being said, if we instead spend a massive amount of time in the first half, we may need to think about constructing the package's package-db more intelligently :-/
@purefn so we went from ~150min to ~65min for single core compilation? Impressive! How much faster is `stack` with single core compilation?
@codygman is this with a fresh stack build or with a warm cache? Taking 3x as much time would indicate to me that haskell.nix is building something that stack isn't?...
@codygman that would be helpful. I'm not that familiar with `stack`; nix will however start from scratch each time to force reproducibility, except for cached libraries. If we build the...
This is an intersting case. And I very much believe you are on the rigth track here. We are probably trying to access some postgresql specific logic at compile time....
@miuirussia I assume you figure out how to fix this? It is true that `stack-to-nix` ignores the `nix` section. `stack-to-nix` just translates the lts + packages into a build plan....
@miuirussia patches welcome! `stack-to-nix` lives in github.com/input-output-hk/nix-tools, the binaries are all pretty simple haskell programs.
@thomasjm awesome!
Thanks for bringing this up @rvl! Yes naming has been a sore point. I've started to emphasise `haskell.nix` more over `nix-tools`. Specifically because `nix-tools` only does the translation and `haskell.nix`...
We also have `iohk-nix`, which uses `haskell.nix` as building blocks to build our high level interface. @nomeata has been running into this a bit, and is probably not too happy...