Is buildBazelPackage from nixpkgs supposed to work?

[robinp]

When I try, I get:

ERROR: /tmp/nix-build-foobar.drv-0/source/BUILD:8:1: no such package '@ghc//': Platform is not supported (see 'fail_not_supported') and referenced by '//:ghc-impl'

This is not much error to help troubleshooting, but asking first to see if you attempted and succeeded already.

[robinp]

Hm, the problem seems to come from

rules_nixpkgs/nixpkgs/nixpkgs.bzl

Line 60 in 40b5a9f

return repository_ctx.which("nix-build") != None

and that nix-build is not available when running in a build already. Any idea to shortcut this (for example by passing in the repos externally)? Or just avoid packaging bazel output by nix?

[Profpatsch]

This is what I understand you are trying to do:

Use rules_nixpkgs to build a nix derivation which internally uses buildBazelPackage.

Is that correct?

[robinp]

Hm, good question. I'm trying to use buildBazelPackage on a target of a Bazel repository which uses rules_haskell and with it rules_nixpkgs to provision ghc. I'm not sure which project this bug should be against.

The point is, I want to package up a rules_haskell target's build result as a nix derivation so it can be properly built and deployed using nix. Maybe my approach is wrong.

[Profpatsch]

The point is, I want to package up a rules_haskell target's build result as a nix derivation so it can be properly built and deployed using nix. Maybe my approach is wrong.

Nope, it’s the right approach.

So the problem I see is that your application uses rules_haskell with a rules_nixpkgs backend, meaning it triggers the whole “no nix inside nix” problem. The solution here is to override your project’s WORKSPACE file in a way that does not use rules_nixpkgs to fetch external packages. Can you point me to the WORKSPACE file?

[matthewbauer]

I am hitting the same issue. You can kind of make it work with a fake nix-build script that hardcodes the attributes that will be needed for bazel fetch && bazel build. But now I am getting issues with the bazel fetch getting different hashes each time. Might have something to do with cabal2bazel & others?

[robinp]

@Profpatsch the repo is https://github.com/TreeTide/underhood. I would be thankful if you could point me how to get it built.

I plan to use a nix-based GitLab CI runner by the way. Wondering if the Bazel build cache could survive. But first would be happy if it worked at all.

(Note: when deploying, I now manually bazel build the binaries and make the hacky https://github.com/TreeTide/underhood/blob/develop/treetide/underhood/wrapup_binaries.nix pick them up, which is less than ideal).

[Profpatsch]

You’ll have to replace

nixpkgs_package(
    name = "ghc",
    build_file = "@io_tweag_rules_haskell//haskell:ghc.BUILD",
    nix_file = "//:ghc.nix",
    repositories = {"nixpkgs": "@nixpkgs//:nixpkgs.nix"},
)

in your WORKSPACE with something that points to the ghc you are using inside of nix. nixpkgs_package is just a wrapper around a call to nix-build.

If you are lucky, it is enough to change nix_file to nix_file = "${myGhc}", so that nixpkgs_package invokes nix-build … -- /nix/store/…-ghc, which might just work inside of another nix build (but I haven’t tested).

[robinp]

@Profpatsch thanks, got quite far using new_local_repository rules. Now the (hopefull last) blocker is how to pass the libraries attribute to haskell_toolchain (see tweag/rules_haskell#973 (comment)).

If that gets sorted, I will post a working example.

Update: this seems to be working now (see the linked issue), but I have some trouble setting up the nixy cc_toolchain yet. Will post about progress.

Update: turns out I just forgot to uncomment the cc_toolchain setup. Victory!

[Profpatsch]

Nice! Does this mean I can close this then? Is there some best practices documentation we can get out of this?

[robinp]

Closing it, thx! Will ping with an example (now got it to build with buildBazelPackage, just want to see if it would work on Hydra as well).

[robinp]

FYI posted full example of a Nix + Bazel + Haskell repo, which can build both with bazel on command-line, as well as bazel from inside nix-build, at https://github.com/TreeTide/haskell-bazel-nix-template.

[SomeoneSerge]

replace ... with something that points to the ghc you are using inside of nix.

Ouch. Is there no way around this?

[SomeoneSerge]

Can't we patch bazelBuildPackage somehow that it parses nixpkgs_package rules and prepares them into that deps archive it generates?

[aherrmann]

Maybe the situation could be improved using Bazel's --override_repository flag, which can be used to replace a repository, e.g. a nixpkgs_package invocation, by some local directory, e.g. a Nix store path. Parsing the WORKSPACE file for nixpkgs_package sounds hard to get right, since the nixpkgs_package might be hiding behind a macro, e.g. most of the toolchain rules provided by rules_nixpkgs. However, one could use Bazel's --experimental_workspace_rules_log_file flag and discover all nix-build invocations in the log. A packager could then generate appropriate override_repository flags. This will need a bit of extra work on the Nix side to generate the BUILD file and make sure that any nix_file and nix_file_deps are in the right place. The workspace log might turn out useful for these as well.

[thufschmitt]

Fwiw, Nix has an experimental support for “recursive-nix` (see NixOS/nix#3205) which could be used for this