cachix unreliable

[MangoIV]

@fufexan

I have noticed that I'm building hyprland very often.

It would be nice if there was a more reliable way of getting the cached version over hyprland (perhaps by using the nixpkgs pinned by hyprland in the overlay or at least exposing an overlay that acts like that?)

[fufexan]

There are several explanations why Cachix would not work:

1. Using overlays. Those will use your configuration's nixpkgs which is most likely not matching the Hyprland flake's nixpkgs.
2. Manually overriding inputs.hyprland.inputs.nixpkgs.
3. Incorrect Nix settings.

Might I ask for the Hyprland path you currently have on your system? I want to look it up on Cachix to see if it's there. (realpath $(which Hyprland))

[MangoIV]

As already pointed out in my issue, I'm pretty sure that the reason for it not working is my use of the overlay. It makes sense to have it normally just reuse the nixpkgs that it gets passed but in this case it might make sense to expose an overlay that ignores the nixpkgs passed but instead uses the one pinned in hyprland.

[MangoIV]

so what I propose is something like

(self: super: let pkgs = inputs.nixpkgs.legacyPackages.${super.system}.appendOverlays [ .. ]; in { ... })

[MangoIV]

for now, as a downstream user, if you're reading this, instead of using the overlay directly, use

(_self: _super: inputs.hyprland.packages.${system})

as an overlay

[MangoIV]

@fufexan I guess you can remove the bug label, it's moreso a feature request. Thank you for your help :)

[fufexan]

I usually do not recommend using overlays precisely due to these kinds of issues. What I'm thinking of doing is using flake-parts' easyOverlay module, when I'll have time to transition the flakes. That also solves the issue.

[MangoIV]

flakeParts would be a nice addition, I have yet to change my config to that as well.

[fufexan]

Do the current overlays work? Can I close this issue?

[musjj]

Another explanation is that the cache might have expired already. For example the cache for the latest stable release 0.35.0 from just 2 weeks ago already expired (I was trying to soft-transition from nixpkgs to the upstream flake).

You can check with curl http://hyprland.cachix.org/q329r4vivn0dfa3y281px88vj5cvpqiy.narinfo.

[leon-erd]

I also have to compile Hyprland quite often lately :thinking: I have tried with the overlay and also by setting package = inputs.hyprland.packages.${pkgs.system}.hyprland; as suggested in the wiki. realpath $(which Hyprland) returns /nix/store/cmavya2mbrnk1mxghc4nwzlhkm1l2gjx-hyprland-0.36.0+date=2024-02-29_1698d33/bin/Hyprland.

[musjj]

Looks like that the store hash is different from the one pushed by the CI: https://github.com/hyprwm/Hyprland/actions/runs/8100075664/job/22137285516

Did you override any of the flake inputs (e.g. nixpkgs)?

[leon-erd]

For hyprland I didn't override anything it's just hyprland.url = "github:hyprwm/Hyprland";

[musjj]

Ah, I think this is the exact issue I was facing with this: https://github.com/Aylur/ags/pull/328

For some reason, using nix-installer-action from DeterminateSystems:

https://github.com/hyprwm/Hyprland/blob/f590505daf90dfb4059289a906863b59663e70a6/.github/workflows/nix-build.yml#L22

causes the store hash produced in the CI to differ from local builds. It's a really weird issue and I have no idea what's causing it.

But for now, simply changing the action to cachix/install-nix-action@v25:

- - uses: DeterminateSystems/nix-installer-action@main
+ - uses: cachix/install-nix-action@v25

fixes the issue for me. Not sure if this solution works for this case in particular, but it may be worth a try.