Mathieu Boespflug

@crossleydominic great tips. Would be nice to have this in the [use cases documentation](https://rules-haskell.readthedocs.io/en/latest/haskell-use-cases.html). > you'll have to combine this compiler flag with the bazel build flag --sandbox_writable_path Yes. Although,...

Nice workaround, but let's reopen - because perhaps we could consider doing this by default?

I think this problem goes away if we have recursive Nix. cc @edolstra @adisbladis If Nix was happy to be called recursively, we wouldn't need any toolchain, which in any...

We have a test for this: https://github.com/tweag/rules_nixpkgs/blob/8c098688bc52c39829f4629d0f27edd51571a771/WORKSPACE#L59-L65 And indeed, if the `nix_file_deps` attribute is commented out, the test still succeeds, even though it should not. That's a more minimal repro.

As is documented in the README, `nix_file_deps` refers to the dependencies of `nix_file_content` or `nix_file`, not `repositories`. Both the test above and @guibou's original repro misuse the `nix_file_deps` attribute. We...

> My point of view here is that bazel must invalidate if any of the file used in the process of nixpkgs_package change. There is nothing else which matters (from...

I think this is a good idea. Though to be useful the json file you mention should be checked into the source, right? So that even the initial checkout isn't...

Conceivably, Hydra could generate that for all of Nixpkgs though. Then we don't even need to checkin anything. @zimbatm isn't that what you have setup in some private Hydra instance?

To be honest, as argued in detail in #617, neither Stack nor Cabal are appropriate for a project of this complexity. We are currently abusing Setup.hs scripts in ways that...

I'm not claiming that the code satisfies the spec, but I'm claiming that the spec is not made available to downstream modules. I can reproduce even with HEAD. See https://github.com/mboes/liquidhaskell-issue-2132.