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...