No nixpkgs input in flake.nix

[jeslie0]

This isn't an issue per se, but it might be related to one. The flake.nix file only has one input and it is not nixpkgs, even though it uses nixpkgs in its output expression.

Is there a particular reason why nixpkgs isn't specified as an input? A bug I have found with this flake is that I can only pull a build from cachix if my system's nixpkgs commit matches the one used to build on hydra. Maybe this is related to there being no nixpkgs input for the flake?

[leungbk]

I asked in the NixOS Discord:

Someone pointed out that they are able to hit the emacs-overlay cache only when their nixpkgs matches one of the revs used by the overlay's Hydra instance. (https://github.com/nix-community/emacs-overlay/issues/262) Notably, flake.nix and default.nix do not specify a nixpkgs rev.

If I were to rewrite the overlay to explicitly specify a nixpkgs rev in the flake.nix, could this cause a user's other overlays for either Emacs or something in its dependency closure to silently no-op (due to the flake's nixpkgs rev differing from the user's nixpkgs rev)?

The response I got:

The overlay should not use a fixed commit, an overlay should always use the users nixpkgs, they might want to use a different one for a reason.

[jasonjckn]

@jeslie0 an overlay can be applied to a nixpkgs github input if you so chose, it's completely flexible/agnostic.

even if you added a new input for nixpkgs into emacs-overlay, that would only affect #packages.system.emacs, not #overlays. (unless you write pathological code)

[jeslie0]

My issue is that I can't pull emacs from cachix unless my system's nixpkgs revision matches the one used to build the package on hydra. Every time I want to update my emacs to a newer commit, I need to also update every package on system, matching my nixpkgs rev to one used to build a version of emacs on hydra. Ideally, I would like to separate the two, which is one of the selling points of flakes.

One option would be to only use my system's nixpkgs for emacs, and use another revision for every other package. This still ties things like services to emacs's nixpkgs revision though.

[tadfisher]

The typical solution is to define a nixpkgs input so it is locked in the flake, and allow users of packages.${system}.<package> to override with inputs.nixpkgs.follows = .... As @jasonjckn said, this doesn't affect users of the overlay, as designed.

Currently, there is almost zero chance of getting a cache hit, even if you choose to use an attr in packages.${system} instead of applying the overlay, unless you lock your own nixpkgs input to the same revision as the one locked in this repo manually.

[573]

The typical solution is to define a nixpkgs input so it is locked in the flake, and allow users of packages.${system}.<package> to override with inputs.nixpkgs.follows = .... As @jasonjckn said, this doesn't affect users of the overlay, as designed.

Currently, there is almost zero chance of getting a cache hit, even if you choose to use an attr in packages.${system} instead of applying the overlay, unless you lock your own nixpkgs input to the same revision as the one locked in this repo manually.

This is what I observed as well, emacs always gets rebuilt when my other inputs are updated. For the aarch64-linux system closure I build in ci via github actions this ends up being virtually impossible (with free plan) so I always rebuild on device pushing to my binary cache then.

[accelbread]

I noticed flake.lock is missing as well.

Yes, the overlay should use user's nixpkgs, but it will still do so if we add a nixpkgs input and flake.lock. Since the overlay gets its packages from the overlay parameters it will only use the nixpkgs it is applied too.

Adding the locked inputs would make the flake packages output use a fixed nixpkgs; this way nix build github:nix-community/emacs-overlay#emacsPgtk would be use the locked nixpkgs and people who want to always hit the cache can use emacs-overlay.packages.${system}.emacsPgtk instead of applying the overlay and using pkgs.emacsPgtk.

[jeslie0]

Thank you so much for fixing this. I can now pull the emacs packages from cachix consistently.