Packaging 128 languages with Nix
37 points by noon
37 points by noon
I often look at Nixpkgs to get a clear sense of how difficult to package a piece of software is.
And if some piece of popular software is not on Nixpkgs, it is usually safe conclude that it's been made artifically hard to package (cough cough Sentry).
I feel like there's a subtle misunderstanding in the "Why use stable nixpkgs?" part. Using the nixos-25.11 branch doesn't cause you to have more re-use capability than using nixos-unstable would. What's more important is that multiple repositories should have their nixpkgs input in sync. This way you can maximise re-use, regardless of unstable/stable.
The stable channels do often get (security) updates, and if there is such an update to a package sufficiently close to the root of the build tree, having differing nixos-25.11 pins – one including that update, one not – will prevent pretty much any re-use.
yes; that's what i tried to say 😅
thanks for pointing out that it's confusing; i'll try and clarify in the post.
what i was trying to express is that if you go around making a bunch of repos on your computer with nixos-unstable; you're very likely to get wildly different hashes in your flake.lock. but if you stick with nixos-25.11; chances are you get much more hash agreement.
chances are you get much more hash agreement
I don't think this is true to a relevant scale. There are staging cycles on release-25.11 about as often as there are on master. There, commits causing lots of rebuilds are collected to be merged together. See this nixpkgs PR for example. It includes a change on python313, which is a dependency of stdenv. After this PR was merged, nixos-25.11 was updated to include this PR. Every single package depending on stdenv had to be rebuilt. If you have two repos, one pinned to a nixos-25.11 from before this PR hit, and one after, you'll have to build pretty much everything twice.
Admittedly, you will get a lot more changes when on nixos-unstable in comparison to nixos-25.11, but the changes not going via a staging cycle are to leaf-ish packages, which are mostly unlikely to impact your packages.
My point is, sticking with nixos-25.11 will not really prevent rebuilds, keeping the nixpkgs you depend on in sync across repos will, regardless of nixos-25.11/nixos-unstable.
Yeah, this is optimizing for less nix store bloat, not reproducibility (which you can guarantee in either case).
I didn't get the but about gambas being replaced with nix. What does that mean?
supposing you can even build the gambas3 library; when it runs it expects libraries to exist at /usr/lib/...; you can see this in the source:
> git clone https://git.launchpad.net/ubuntu/+source/gambas3
> cd gambas3 && rg '/usr/lib' | wc -l
510
one fix is to update all these references; but a much simpler fix is to use buildFHSEnv and just wrap the binary, so it has what it expects at runtime:
... in pkgs.buildFHSEnv {
name = "gambas3-wrapped";
runScript = "${gambas.outPath}/bin/gbs3";
targetPkgs = _: [ gambas ];
};
i hope this makes sense.
The PR (probably among other things) removes Gambas from the quine relay and replaces it with Nix (the programming language). So instead of Ruby -> ... -> Fortrango -> Gambas -> GAP -> ... -> Nickle -> Nim -> Objective-C -> ... -> Ruby the quine relay would go Ruby -> ... -> Fortrango -> GAP -> ... -> Nickle -> Nim -> Nix -> Objective-C -> ... -> Ruby.