Moritz Angermann

I've just opened irc://irc.freenode.net/#haskell.nix

@michaelpj, I actually like `haskell.nix-tools` as suggested by @nomeata, any specific reason you don't like that one?

@michaelpj so you'd prefer `haskell.nix/tools` or `tools.haskell.nix`? `nix-tools` will essentially contain *all the tools* related to `haskell.nix`. If we fix `build` in there somehow, we will need yet another repository...

> `haskell.nix/tools` this of course was a lure :p we are just replacing `/` by `-` ;-) > `haskell.nix/tools` suggests another question: why not merge `nix-tools` into `haskell.nix` as a...

Alright. I'll go and let this sit for now. Maybe @michaelpj can convince me in two weeks that he's right and I'm wrong 🍻

This seems to be the same as #214? Does adding `c2hs` as an extra dependency help?

@chreekat that is a valid question. Maybe we should put it behind a flag for now and disable it by default? Are you keen on a challenge?

So what you ultimately want is to collect the test-derivations for all the "active" packages?

This turns out to be a bit more tricky, `stack-to-nix` will aggregate `packages:` and `extra-deps:` https://github.com/input-output-hk/nix-tools/blob/b1efc35f344995f546b14da7914d7c0c0cdf5fa8/stack2nix/Stack2nix/Stack.hs#L181-L188 Hence I beleive the solution here would have to be to annotate the parsed...

@kutyel what does “all packages” mean? stack-to-nix will merge extra-deps and packages when parsing the stack file. We could probably get that set (packages + extra-deps) separately. However without knowing...