How should we package Zig software?

Development
1

I hope this is the correct place to ask / discuss this:
I was wondering how Zig software should be packaged in nixpkgs.

So far I have used either GitHub - nix-community/zon2nix: Convert the dependencies in `build.zig.zon` to a Nix expression [maintainer=@figsoda] · GitHub or GitHub - Cloudef/zig2nix: Flake for packaging, building and running Zig projects. · GitHub to generate a build.zig.zon.nix from a zig project’s build.zig.zon file.
The build.zig.zon.nix would contain fetchers for the zig deps (example here) and would be called from the package.nix.
I have seen it being called like this or like this.

Alternatively, I recently discovered we also have zig.fetchDeps which would use zig rather than nix to fetch the deps as far as I understand (example here).
To me, using zig.fetchDeps seems like the way to go. Because we wouldn’t need to add extra files to fetch the deps using nix and would stick closer to how zig works outside of nixpkgs. This probably also works around some limitations of zon2nix and zig2nix which still fail for some use cases.
I assume this also integrates more easily into nix tooling like nix-update.

However, so far I have only done some maintenance on nixpkgs and I don’t think I have a deep enough understanding to see all advantages / disadvantages of either approach. So I thought I’d post this to ask for opinions or start a discussion. Maybe we can even derive a default approach to package zig software. I’d be down to update the things we packaged up until now and write a wiki entry or something if we arrive at a best practice or something.

2 Likes
2

The way that the majority of Zig software is packaged in nixpkgs is by using zon2nix because of the high potential for FOD hash breakage, which is a nightmare when it comes to maintenance.

I actually have a PR in the works (zig: replace generated dependencies with fixed-output derivations by water-sucks · Pull Request #438523 · NixOS/nixpkgs · GitHub) that ports all Zig packages to use fetchDeps, but there have been problems with package fetchers (most notably the pnpm ecosystem) that have had mass FOD hash breakages due to the way pnpm changes their package structure from release to release without notice. Since Zig is a pre-1.0.0 language and there’s seemingly no guarantee of FODs staying stable, I don’t think my PR would get merged for the time being until andrewrk declares that the package directory format and/or hash format that packages are addressed by is stable.

4 Likes