Hacker News Reader

Comment by mikepurvis | Hacker News Reader

Whoa, nifty. Can you speak more to the interop issues with Nix? I've been working on a pretty large Nix deployment in the robotics space for the past 3ish years, and the infrastructure side is the biggest pain point:

* Running a bare `nix build` in your CI isn't really enough— no hosted logs, lack of proper prioritization, may end up double-building things.

* Running your own instance of Hydra is a gigantic pain; it's a big ball of perl and has compiled components that link right into Nix internals, and architectural fiasco.

* SaaS solutions are limited and lack maturity (Hercules CI is Github-only, nixbuild.net is based in Europe and last I checked was still missing some features I needed).

* Tvix is cool but not ready for primetime, and the authors oppose flakes, which is a deal-breaker for me.

Something that's a barebones capable of running these builds and could be wrapped in a sane REST API and simple web frontend would be very appealing.

View on HN

Tracking issue is https://github.com/256lights/zb/issues/2

The hurdles to interop I see are:

- Nixpkgs is not content-addressed (yet). I made a conscious decision to only support content-addressed derivations in zb to simplify the build model and provide easier-to-understand guarantees to users. As a result, the store paths are different (/zb/store instead of /nix/store). Which leads to... - Nix store objects have no notion of cross-store references. I am not sure how many assumptions are made on this in the codebases, but it seems gnarly in general. (e.g. how would GC work, how do you download the closure of a cross-store object, etc.) - In order to obtain Nixpkgs derivations, you need to run a Nix evaluator, which means you still need Nix installed. I'm not sure of a way around this, and seems like it would be a hassle for users.

I have experienced the same friction in build infra for Nix. My hope is that by reusing the binary cache layer and introducing a JSON-RPC-based public API (already checked in, but needs to be documented and cleaned up) for running builds that the infrastructure ecosystem will be easier.

I've been wondering idly if it's possible for Nix to support the Bazel Remote Execution API that seems to be catching on[1] more generally.

[1] https://github.com/bazelbuild/remote-apis?tab=readme-ov-file...

I’m very interested in better bidirectional interop between bazel and nix; it seems such a travesty that for two projects that are so ideologically aligned to work so poorly together. Nix should be able to run builds on bazel and bazel builds should decompose and cache into multiple store paths in a nix environment (think how poetry2nix works).

If you're attending BazelCon I'd love to have a chat with you about this stuff in some more detail. (If you're not I'd still love to have a chat!)

I'm afraid I'm not planning on it; I don't make it to the west coast nearly as often as I should. Feel free to hmu on LinkedIn or something though; I'd love to get plugged into some people interested in this stuff, and I'm about to have a block of time available when I could potentially work on it.

Why are flakes such a deal-breaker? While not ideal, you can still tag your versions in the .nix file instead of the lockfile.

I even had to avoid flakes in a system I developed used by ~200 developers since it involved a non-nixos OS and it involved user secrets (Tokens etc...) So with flakes I had to keep track of the secrets (and was a pain point, since they obviously didn't have to push them into the git repo) but nix flakes doesn't handle well omitting files on git (it ignores them also on nix commands). In the end, the workarounds were too messy and had to drop flakes entirely.

As a new user, I learned flakes first, and the tie-in with git tags/branches and the corresponding cli ergonomics aren’t something I’d be able to give up.

How do you handle flakes pushing an entire copy of the repo into the nix store? Is this not an issue for you somehow?

The repo being evaluated? Not an issue for me. In the dev scenario disk is plentiful; in production it can be garbage collected out or avoided by using copy-closure type workflows or nix2container (eg just not running nix evaluations directly in the target environment).

That makes sense. I naively tried flakes for a nix-shell replacement for a couple environments, one was a node app with large node_modules dependencies and the other was a windows app I was running in a local wine root. In both cases re-evaluating the flake was very slow because of the volume of data being copied. I want to do more with flakes but I’m skeptical that they end up being a good per-app workflow when the whole app isn’t using nix for build and dependencies end-to-end.

Yes, that's fair. I wouldn't be trying to use Nix at all if I was wanting to depend on stuff outside of it— fortunately nixpkgs already has decent coverage in the scientific computing space, so most of what we needed for a ROS/robotics application was present, and the remainder wasn't too bad to just package ourselves.

That said, I think the node story overall is still pretty rough. There are several competing tools/workflows each with different tradeoffs. My frontend team did a brief evaluation and basically just noped out of it— there's so much tooling in the node world that just gets you directly from your lockfiles right to a deployable container, it's harder to see the value of a Nix closure as an intermediate build object; the case is a lot less clear for it than for, say, Python or C++ stuff.

https://github.com/edolstra/flake-compat should make flakes work with tvix

Reply on news.ycombinator.com