Will using nixpkgs-unstable instead of the ambiguous nixpkgs, in flake.nix follows expression cause a lock difference? Claude says so...

[nick-walt]

Hi Lucca,

I've made my reference to nixpkgs more explicit by introducing nixpkgs-stable / nixpkgs-unstable and pkgs-stable / pkgs-unstable into flake.nix in Nixos and Home Manager. In my mind this should just be treated as sugar and resolved or evaluated down to the same underlying mechanisms without causing any issue -- but Claude says otherwise:

Your consumer flake has its own flake.lock recording whichever commit nixos-unstable pointed to the last time you ran nix flake update. Yazelix's flake.lock records whichever commit it pointed to the last time Yazelix's maintainers ran theirs. Same URL, same branch — but two independently-frozen snapshots of a branch that moves daily.

So "the sugar disappears and both resolve to the same URL" is true only up to the URL string itself. It is not true of the resolved value each flake actually evaluates against, because the URL alone under-specifies a flake input — the lock file's commit hash is the actual identity, and that's decided per-flake, independently, unless follows explicitly overrides it.

Sounds like faulty reasoning to my current level of understanding, and nixos-and-flakes.thiscute.world references indicate that this pattern is indeed just sugar.

My Home Manager flake.nix:

{
  description = "Home Manager configuration of <username>";

  inputs = {
    nixpkgs-stable.url = "github:nixos/nixpkgs/nixos-26.05";
    nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";

    yazelix = {
      url = "github:Yazelix/nova/stable";
      inputs.nixpkgs.follows = "nixpkgs-unstable"; #Maybe this should be inputs.nixpkgs.follows = "pkgs-unstable"; ?
    };

    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs-stable";
    };
  };

  outputs = inputs@ { self, nixpkgs-stable, nixpkgs-unstable, yazelix, home-manager, ... }:
    let
      system = "x86_64-linux";
      pkgs-stable   = import nixpkgs-stable   { inherit system; };
      pkgs-unstable = import nixpkgs-unstable { inherit system; };
    in
    {
      homeConfigurations."<username>" = home-manager.lib.homeManagerConfiguration {
        pkgs = pkgs-unstable;
        extraSpecialArgs = { inherit inputs pkgs-stable pkgs-unstable; };
        modules = [
          ./home.nix 
        ];
    };
  };
}

Do you see a problem? My assertion is that my flake.nix resolves both stable and unstable to their respective URL assignment to nixpkgs so it won't create a different cache variation (nixpkgs instances) in flake.lock (trying to understand more about the inner workings of Nix and Nixos / Home Manager). Cheers.

[nick-walt]

The final Home Manager flake.nix:

{
  description = "Home Manager configuration of username";

  inputs = {
    nixpkgs-stable.url = "github:nixos/nixpkgs/nixos-26.05";
    nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";
    nixpkgs-yazelix.url = "github:NixOS/nixpkgs/567a49d1913ce81ac6e9582e3553dd90a955875f";

    yazelix = {
      url = "github:Yazelix/nova/42b0e0c490a3b940f9a2df2d5672afa4cf28c79f";
      inputs = {
        nixpkgs.follows = "nixpkgs-yazelix";
        yazelixScreen.inputs.fenix.follows = "yazelix/novaBar/fenix";
        yazelixZellijPaneOrchestrator.inputs.fenix.follows = "yazelix/novaBar/fenix";
        yazelixZellijPopup.inputs.fenix.follows = "yazelix/novaBar/fenix";
        yazelixHelix.inputs.rust-overlay.follows = "yazelix/rio/rust-overlay";
        zjstatus.inputs.rust-overlay.follows = "yazelix/rio/rust-overlay";
        yazelixZellijPopup.inputs.flake-utils.follows = "yazelix/yazelixZellijPaneOrchestrator/flake-utils";
        zjstatus.inputs.flake-utils.follows = "yazelix/yazelixZellijPaneOrchestrator/flake-utils";
      };
    };

    home-manager = {
      url = "github:nix-community/home-manager/release-26.05";
      inputs.nixpkgs.follows = "nixpkgs-stable";
    };
  };

  outputs = inputs@ { self, nixpkgs-stable, nixpkgs-unstable, yazelix, home-manager, ... }:
    let
      system = "x86_64-linux";
      pkgs-stable   = import nixpkgs-stable   { inherit system; };
      pkgs-unstable = import nixpkgs-unstable { inherit system; };
    in
    {
      homeConfigurations."dev" = home-manager.lib.homeManagerConfiguration {
        pkgs = pkgs-stable;
        extraSpecialArgs = { inherit inputs pkgs-stable pkgs-unstable; };
        modules = [
          ./home.nix
          ./yazelix.nix

        ];
      };
    };
}

This resulted in the compilation of the major applications as Cachix was bypassed. About 30 minutes of 100% usage on 12 "host" type vCPU-cores (mapped 1:1 to host CPU cores) and 70% usage of 64GB RAM assigned to a virtual machine.

yazelix.nix:

{ inputs, pkgs, ... }:
{
  imports = [ inputs.yazelix.homeManagerModules.default ];

  programs.yazelix = {
    enable = true;
    package = inputs.yazelix.packages.${pkgs.stdenv.hostPlatform.system}.yazelix-no-rio;
  };
}

[luccahuguet]

hi, thanks for reaching out, this is Astra's take:

Your intuition about the names is right: naming an input nixpkgs-unstable rather than nixpkgs does not itself change the packages or prevent cache reuse. Claude's distinction about lock files is also correct: two inputs pointing at the same branch URL can be locked to different commits.

follows = "nixpkgs-unstable" selects that input's locked revision. Keep the flake input name there; pkgs-unstable is your local imported package set, so it is not a valid replacement in this configuration. The Nix input reference explains how these paths work.

Your later configuration also changes internal dependencies. I checked Nova's lockfile at your selected revision: Helix and Rio have different rust-overlay revisions, and the pane orchestrator and Nova Bar have different fenix revisions. Making those inputs follow each other changes the selected dependencies even though you kept Nova's nixpkgs commit. That can change build paths and prevent reuse of the corresponding published binaries.

For a default install, I would simplify Nova's declaration to:

inputs.yazelix.url = "github:Yazelix/nova/stable";

Remove the nested Nova input overrides and keep your yazelix-no-rio package selection. Your host and Home Manager can retain their own stable/unstable inputs. If you want to isolate the effect of the overrides, keep your existing exact Nova commit while removing them.

Also verify that the Yazelix cache URL and public key are enabled in the Nix configuration that controls your builds. The changed dependencies are a plausible explanation for rebuilds, but the posted configuration alone does not prove whether your cache was ignored or lacked matching outputs.

The Home Manager guide includes the simpler default, explicit cache setup, optional overrides, and a dry-run command for inspecting the build plan.

[nick-walt]

Hi Lucca, it is interesting that GPT6 sees no value in refining the dependency nodes and it is not clear if it actually analysed the differences between the instances. Yazelix is running for me so far so will keep the config that removes the redundancies across what should be a singular node -- as you have done with all your modules. The coupling that will definitely, 100% break in my config will be the pinning of Yazelix to its version's specific Commit. I'll try to write a function that automatically finds and inserts the specific Commit of each Yazelix release during evaluation.

Thanks.

[luccahuguet]

Fair point: deduplication has value, and the earlier answer should have distinguished identical dependency graphs from overrides that change them.

We rechecked the sources and recursively resolved dependencies in the lockfile at your selected Nova revision:

Override	Comparison
Screen's Fenix → Nova Bar's	Identical source and dependency graph.
Popup's Fenix → Nova Bar's	Same Fenix revision, but different nixpkgs dependencies.
Pane orchestrator's Fenix → Nova Bar's	Different Fenix revisions.
Helix/zjstatus's rust-overlay → Rio's	Different rust-overlay revisions.
Popup/zjstatus's flake-utils → pane orchestrator's	Identical source and dependency graphs.

So some of your overrides do consolidate genuine duplicates. Others select different build inputs. We haven't compared the resulting derivations with and without your overrides, so changed inputs remain a plausible explanation for the rebuilds, not a proven diagnosis of what happened to cache reuse.

Consolidation is worth considering in Nova itself where we can validate the resulting packages and publish matching cached builds. That would let everyone benefit without maintaining overrides into Nova's internal dependency graph. Your configuration working is useful evidence, too.

On the commit pin: an exact Nova commit keeps that version selected; it doesn't inherently break the configuration. If the goal is to follow Stable while retaining reproducibility, Nix already handles the commit lookup:

inputs.yazelix.url = "github:Yazelix/nova/stable";

Then, from your configuration's flake directory, update deliberately:

nix flake update yazelix

The lockfile records the exact commit selected from Stable. There is no need for a function that finds and inserts it during evaluation. See the Nix update documentation.

If you meant keeping nixpkgs-yazelix synchronized with each Nova release, leaving Nova's nixpkgs input unoverridden lets Nova's own lockfile supply that revision; a separately maintained matching pin isn't needed.

[luccahuguet]

im glad you pushed a bit, nick

im creating an issue to track this

it does make sense to deduplicate

[luccahuguet]

Tracking this in #697 — Deduplicate compatible Nova flake inputs, paired with our Bead. We’ll start with identical dependency graphs, assess compatibility before aligning differing pins, and verify the resulting builds and cache delivery on Linux and macOS. Thanks for raising it.

[luccahuguet]

Hi Nick, the compatible deduplication is implemented on Edge in 6a58ea9b, and #697 is complete.

Five native follows declarations reduce Nova's lock graph from 55 to 45 nodes:

• Anima (the yazelixScreen input) and the pane orchestrator share Nova Bar's Fenix.
• Popup, Radar and zjstatus share the pane orchestrator's flake-utils.

We compared the actual builds this time: all 80 derivation/output pairs match before and after—11 public package outputs and nine child outputs across the four supported systems. The pane orchestrator's previous Fenix revision differed, but its consumed stable Rust/Cargo/WASI toolchain and plugin build are identical. Root nixpkgs and all application pins remain unchanged.

We kept Popup's Fenix separate because its transitive nixpkgs changes toolchain paths. Helix, Rio and zjstatus also retain their distinct rust-overlay pins and compiler versions. Those would require a deliberate toolchain update rather than equivalent deduplication.

Linux CI, native Darwin package smoke, and both cache publication jobs passed on the exact commit. Isolated installation checks passed, and we verified the published Linux/macOS no-Rio packages and seven Linux child artifacts directly against Cachix, including their contents and signatures. A fresh-eyes and simplification pass also reconfirmed the build identities and found no further fixes needed.

This is on Edge; it has not been promoted to Main or Stable yet. The consolidation lives in Nova, so consumers can benefit through its default graph without maintaining these internal overrides.

We haven't reproduced your original cache environment or measured build-time/disk savings, so this doesn't establish why your earlier build missed the cache. It does establish that this subset removes duplicate input graphs while preserving the packaged build identities. Thanks for pushing us to investigate it properly.

[luccahuguet]

Nick, the follow-up investigation is complete. We opened #698 — remaining Rust toolchain alignment as one public tracker for three separate implementation Beads.

A correction to my earlier update: sharing Helix's rust-overlay does not require upgrading its packaged compiler in the investigated candidate. The editor uses nixpkgs Rust/Cargo 1.95.0; the overlay's stable.latest catalog entry does not determine that build.

The three candidates have different effects:

• Helix: removes one lock node and preserves all 80 compared Nova package/child build identities. Its development shell changes, and its Rust 1.90.0 MSRV check changes on Darwin, so that tooling still needs validation.
• Popup: removes three nodes, including its separate nixpkgs graph. Rust stays at 1.95.0, but toolchain packaging and the Popup plugin would rebuild.
• zjstatus: removes one node and upgrades its composed Nix build from Rust 1.95.0 to 1.96.1. zjstatus and Nova Bar would rebuild.

All three candidates evaluate on four systems. Helix plus Popup would take the current graph from 45 to 41 nodes; all three together would take it to 40. The benefit demonstrated so far is a smaller dependency graph with understood build changes; we have not measured build-time or disk savings.

These follow-ups are planned, not implemented. The tracker covers native Linux/macOS checks, affected runtime behavior, isolated installation and cache delivery. Suggested order is Helix, Popup, then the zjstatus compiler upgrade. The earlier completed deduplication remains tracked separately in #697.

---

AI disclosure: This reply was written by Codex (AI) at Lucca's request, using repository source inspection and Nix evaluation results.

[luccahuguet]

Im using astra

[nick-walt]

How would you compare Astra to Claude with Fable?

[nick-walt]

Thanks for running with this, Lucca. I'm currently working with microvm-nix to change my dev environments from directories / devShell / direnv into specialised persistent Firecracker microvms that feel like directories and will test out Yazelix Nova Edge once I've got one configured.

[luccahuguet]

also, if I got it right, feel free to mark one of my comments as answer

[nick-walt]

Are you able to change the output from the various compilers from verbose to important, warning, critical, error only? When the various programs that make up Yazelix Nova compiled last time the verbosity drowned out some warnings. Cheers.

[nick-walt]

Thanks, and you — I'll try to get some good feedback for you sooner rather than later 👍

[luccahuguet]

Are you able to change the output from the various compilers from verbose to important, warning, critical, error only? When the various programs that make up Yazelix Nova compiled last time the verbosity drowned out some warnings. Cheers.

#699

[luccahuguet]

Thanks, and you — I'll try to get some good feedback for you sooner rather than later 👍

awesome! Thank you very much for your thoughtful contribuitions to yazelix nova

Hey, I know a guy that can get you in the special thanks section, if you want