Lix cache does not match release hash, forces compilation #489
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#489
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the bug
TL;DR: Trying to avoid compiling Lix (because my NixOS servers are potatoes), I thought simply pinning to a tagged version should work, as that's available in the cache, but it doesn't. The difference seems to come from evaluating the package directly when doing the release, but using
callPackage
in the NixOS module.Steps To Reproduce
This is just to show how the two evaluation methods produce different derivations with differing output paths:
Real-life steps to show the issue for users
I want to install Lix on a NixOS-machine, but want to avoid compiling because the CPU is slow. I first modify my configuration to include
cache.lix.systems
as a trusted cache:I then
nixos-rebuild test
and verify the cache has been added:Now, I follow the installation guide, but instead of using
main
, I use the tagged version2.91.0
; inflake.nix
:And later, in
configuration.nix
:Now, when I run
nixos-rebuild
, I can see that Lix will not be substituted, but built:And indeed, when I query the derivation output path, it seems to not be available in the store:
So I took a look at https://releases.lix.systems/lix/lix-2.91.0/manifest.nix, and that contains a different hash for this output:
Which is the one that is available in the cache:
And looking at the closure at https://releases.lix.systems/lix/lix-2.91.0/lix-2.91.0-x86_64-linux.tar.xz, I can also see that it contains the
k4m3...
path, not the one that's generated directly from the archive.I also tried to change
https://git.lix.systems/lix-project/lix/archive/2.91.0.tar.gz
tohttps://releases.lix.systems/lix/lix-2.91.0/lix-2.91.0.tar.gz
, but these two archives seem to be identical, as they both output the33ja...
path. There's a slight difference in the name of their root folder, but I guess Nix doesn't care about that.Expected behavior
I would expect a tagged and released versions of lix to be available in the cache, and I would like that to be the default installation method, not something hidden I can only find by reading the source code.
nix --version
outputAdditional context
Right now there is one other option:
lix-module.nixosModules.lixFromNixpkgs
, but that will lag behind for quite a while (2.91.0 just hit nixpkgs yesterday), and it's currently hard to discover (or I missed the docs for it).My assumption is that the hashes change because of the version of nixpkgs Lix is built against, but as the current lix closure is <30MB small, it seems okay to me to just not care about what version of nixpkgs is installed and instead fetch the entire closure. I believe most people would prefer that to running a >20min compilation.
I now also tried to just remove all
follows
from the module, but that doesn't make a difference:I still get the same derivation path:
This means that it doesn't matter in my case which nixpkgs version I'm following, though I guess that's just because there were no updates to Lix' dependencies between the locked nixpkgs in
nixos-module
and in my flake.Not a bug. The only version of nixpkgs that the cache is built with is exactly the one locked in the Lix flake at the release tag. Not the version in the NixOS module (that exists purely for testing). Not the version in your flake registry as obtained by :lf nixpkgs.
If you want Lix from a binary cache on NixOS, use the build from nixpkgs.
If you want to construct some kind of contraption that does this as described, it is possible to write such an overlay. However this is unsupported and probably broken by operating nixpkgs in ways it is not designed.
final: prev: { lix = lixFlake.packages.${prev.system}; }
, then put it before lix-module.overlays.lixFromNixpkgs and don't override the nixpkgs of the lix flake. This is unsupported for several reasons: the resulting nix-eval-jobs will probably be broken because it links to lix from 24.05 while itself being built with unstable, because that's how overlays work, and there's nothing stopping something else from linking to lix with the same problem either.I dislike flakes very much because they lead to wishful thinking about how overlays work which then wastes a lot of your time diagnosing something that will never work. An overlay will only ever build things from the version of nixpkgs it is evaluated in. It doesn't matter which flake inputs go into the flake exposing the overlay.
The reason lixFromNixpkgs is not documented except in the module readme is that if it were documented elsewhere before lix 2.91 is in both 24.05 and unstable, we would receive several support messages a day asking why it doesn't work. It's much easier to write down the installation method that will always work and which leads to some building while waiting for reviews in nixpkgs (and our own getting the code right).
Also I do see you mention your servers being potatoes. You could set up a binary cache to fix this problem using s3 or cachix or nix-serve-ng or something else entirely, then build it on your fast machine and put it in the cache. Or use nixos-rebuild --target-host to deploy an entire built NixOS system from your fast machine directly to the server without needing a cache.
Thank you for the detailed answer, this really helps a lot!
That's exactly what happened. I thought that the nixpkgs version the Lix uses would be independent from the nixpkgs version that was installed on my system. And I spent multiple hours working out this detailed bug report.
That's very reasonable, thanks for explaining that.
Yeah that's kind-of what I did. I set up the fastest machine I have as a remote builder for the slower ones, then deployed Lix to it first. Serving the store directly might be an option to explore in the future.