Hacker News Reader

Comment by _hl_ | Hacker News Reader

> Building third party flakes takes forever since every flake uses its own version of nixpkgs.

The “official” (as in, community consensus) solution seems to be to bring your own nixpkgs, and manually override the nixpkgs of every dependency (and their transitive dendencies) and verify your build still works. Which just doesn’t seem right to me.

Flakes are great for building an ecosystem of composable, reproducable software. The more they succeed at that, the bigger the problem becomes. Surely it’s not too late to figure out a principled solution before stabilizing flakes?

View on HN

I think the current solution is not too far from an ideal scenario: package the most commonly used dependencies/programs in nixpks (roughly what would be available with other package managers’ default channel/repository), and use flakes as an out-of-tree solution for proprietary/freemium/hard-to-package/very specialist software, similarly to what you might use Docker for.

That way you get the benefit of a minimal-sized system with no size overhead for the most part, yet out-of-tree git repos get reproducible at any commit, and it is even easier than adding a new repo to apt, etc.

With content-addressable hashing, the problem may largely solve itself, reusing unchanged dependencies between older flakes.

The traditional way is to reduce the surface area of the core package as much as possible, such that it sees less changes/releases overall.

The way I would do it with nix is: because everything gets hashed, just check that the built output with a new nix-pkg version matches the hash with the old version and fail out/fetch the older version as a second step. The rest is just finding ways to cache that build fail information so that you can share the result across users transparently.

There is work on content-based hashing, but that is not only related to flakes. So that problem may get solved, and is likely the correct path forward.

This depends, Hyprland has their own flake, and rather than overriding nixpkgs they recommend adding their cachix binary cache. You get binaries for Hyprland from Cachix and for it's dependencies from cache.nixos.org.

Works well for me. Though when doing configuration changes I usually pass --no-substitutes (or smth) to not query all my subs for derivations that'll never be in a remote cache.

Reply on news.ycombinator.com