most dev flake inputs flake=false by mightyiam · Pull Request #4294 · nix-community/nixvim

mightyiam · 2026-05-15T06:55:37Z

This sets flake=false for 5 out of the 8 dev flake inputs.

These 5 inputs seem to support being used as vanilla nix.

This eliminates the inputs.<name>.inputs.<name>.follows.<name> shenanigans.
It also eliminates the risk of failing to notice that an input has a new input.

Yes, we benefit from some flake features, such as purity, eval cache and input pinning.
But we don't have to use inputs as flakes if that incurs a cost and no benefit.

This is how I personally would like to consume flake inputs whenever they support it, including NixVim.
That is discussed in #4288
and is mostly decoupled from this change.

By the way, I tried nix flake check in this repo and ran out of memory.
What's the trick to succeed?

mightyiam

For what it's worth, I've seen worse lockfiles. I've had worse lockfiles. The follows situation here seems minimal. And I don't think that the approach I'm suggesting here is terribly popular, but I think it's based.

mightyiam · 2026-05-15T06:56:28Z

-    "gitignore": {
-      "inputs": {
-        "nixpkgs": [
-          "git-hooks",
-          "nixpkgs"
-        ]
-      },
-      "locked": {
-        "lastModified": 1709087332,
-        "narHash": "sha256-HG2cCnktfHsKV0s4XW83gU3F57gaTljL9KNSuG6bnQs=",
-        "owner": "hercules-ci",
-        "repo": "gitignore.nix",
-        "rev": "637db329424fd7e46cf4185293b9cc8c88c95394",
-        "type": "github"
-      },
-      "original": {
-        "owner": "hercules-ci",
-        "repo": "gitignore.nix",
-        "type": "github"
-      }
-    },


Here is one input less 🕺

mightyiam · 2026-05-15T06:56:48Z

 {
  imports = [
-    inputs.devshell.flakeModule
+    (inputs.devshell + "/flake-module.nix")


Small price to pay?

mightyiam · 2026-05-15T06:57:35Z

    # NOTE: Use a different name to the root flake's inputs.nixpkgs to avoid shadowing it.
    # NOTE: The only reason we specify a nixpkgs input at all here, is so the other inputs can follow it.
    # TODO: Once nix 2.26 is more prevalent, follow the root flake's inputs using a "path:../.." input.
    dev-nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";


Nixpkgs will likely never have its own flake inputs, so I didn't bother.

mightyiam · 2026-05-15T06:58:53Z

flake-compat is also unlikely to have any of its own flake inputs, so I didn't bother.

flake-compat documents flake = false as its recommended usage.

mightyiam · 2026-05-15T07:00:17Z

    nuschtosSearch = {
      # TODO: newer versions fail with: TimeoutError: The operation was aborted due to timeout
      url = "github:NuschtOS/search/b6f77b88e9009bfde28e2130e218e5123dc66796";
      inputs.nixpkgs.follows = "dev-nixpkgs";
    };


This input does not seem to support being used as vanilla. It seems possible with a few lines, but I don't think that we should take that on, especially since it seems to pin its ixx input to some particular version that corresponds with something internal.

mightyiam · 2026-05-15T07:00:58Z

    # keep-sorted start block=yes newline_separated=yes
    devshell = {
      url = "github:numtide/devshell";
-      inputs.nixpkgs.follows = "dev-nixpkgs";


followses be gone!

I'm not entirely sold on flake = false being worth it just for eliminating transitive follows.

Imagine the scenario where an input changes its inputs without us noticing; if we pull it as a flake, then we get their new inputs transitively. If we don't, then things potentially break.

If the reason we can set flake = false is that we are explicitly only using a part of the project that is designed to be used without flake inputs, then that's fine and should probably be documented in a comment.

# Don't pull flake inputs or evaluate outputs. # We exclusively use the flake-module file. flake = false;

Or perhaps a top-level comment along the lines of:

# Avoid `flake = true` when we do not need to evaluate flake outputs or fetch flake inputs. # e.g. when we only import loose files.

TL;DR a) consider whether we're setting flake = false for the right reasons b) consider whether flake = false is fragile and may miss future transitive dependencies c) document why we enable or disable flake in general or for specific inputs.

I've added that single comment above the inputs attribute.

I've pointed out in this PR for each flake=false why it is okay.

I think that projects that expose truly loose files such as /flake-module.nix and /lib/default.nix are aware that users will use them and are not likely to turn them into functions that first take local context such as flake inputs. I prefer this risk over lockfile drift.

mightyiam · 2026-05-15T07:04:23Z

+      { config, ... }:
+      {
+        nixpkgs = {
+          source = self.inputs.dev-nixpkgs;


In the case of this input, the follows actually has a purpose. For what it's worth, I think that the passing of an explicit nixpkgs this way makes more sense, due to it being located here instead of in the flake.nix.

We should prefer inputs.nixpkgs over inputs.dev-nixpkgs.

We enforce that they are the same FOD, but dev-nixpkgs is an implementation detail of the dev-lockfile.

I'll assume you are correct about what we should be doing, but in main, the nix-darwin input has inputs.nixpkgs.follows = "dev-nixpkgs";. Would you like a separate PR that changes that?

in main, the nix-darwin input has inputs.nixpkgs.follows = "dev-nixpkgs";.

In main it is necessary, because of the way nix flake lock works; we cannot follow an input from the top-level lockfile so we introduced dev-nixpkgs as a workaround.

inputs.dev-nixpkgs is a mirror of the top-level flake's inputs.nixpkgs and should only be used when the workaround is necessary.

Or to quote the inline comment:

The only reason we specify a nixpkgs input at all here, is so the other inputs can follow it.

As of this PR, I believe the only input that needs dev-nixpkgs is nuschtosSearch.

MattSturgeon · 2026-05-15T11:47:56Z

+  lib,
 }:
-self.inputs.nix-darwin.lib.darwinSystem {
+(import (self.inputs.nix-darwin + "/eval-config.nix")) {


Is it worth naming this function?

Suggested change

(import (self.inputs.nix-darwin + "/eval-config.nix")) {

let

darwinSystem = import (self.inputs.nix-darwin + "/eval-config.nix");

in

darwinSystem {

Is this a publicly documented usage pattern? I.e. the "official" way to consume nix-darwin without flakes?

Also, because flake inputs are already in-store objects, we could consider using:

"${self.inputs.nix-darwin}/eval-config.nix"

string interpolation.

IIUC, this shouldn't copy-to-store if the path is already a store-object.

Either approach is fine by me, though. You current approach is technically more robust at avoiding potential copy-to-store operations.

MattSturgeon · 2026-05-15T11:51:50Z

 let
-  inherit (self.inputs.home-manager.lib)
+
+  inherit (import (self.inputs.home-manager + "/lib") { inherit lib; })


For readability, is it worth doing something like:

Suggested change

inherit (import (self.inputs.home-manager + "/lib") { inherit lib; })

hmLib = import (self.inputs.home-manager + "/lib") { inherit lib; };

inherit (hmLib)

?

MattSturgeon · 2026-05-15T11:52:21Z

 # To be clear, this is an upstream module system bug, this test validates our workaround.
 let
-  inherit (self.inputs.home-manager.lib)
+  inherit (import (self.inputs.home-manager + "/lib") { inherit lib; })


MattSturgeon · 2026-05-15T11:52:29Z

+  lib,
 }:
-self.inputs.home-manager.lib.homeManagerConfiguration {
+(import (self.inputs.home-manager + "/lib") { inherit lib; }).homeManagerConfiguration {


MattSturgeon · 2026-05-15T11:58:39Z

It's worth noting that the dev-lockfile you've worked on here is not user-facing.

It does not get evaluated by end-users unless they evaluate things like our test suite or dev shell.

MattSturgeon · 2026-05-15T12:02:33Z

By the way, I tried nix flake check in this repo and ran out of memory.
What's the trick to succeed?

I believe this is documented in CONTRIBUTING.md.

IIRC, we still have our entire test suite in the checks output, and when nix flake check tries to evaluate it all in one go it runs out of memory.

We have a tests command in our dev shell that runs the test suite via chunked evals. We also chunk them up in our ci.buildbot output, which you could build using something like nix-fast-build. We should probably look into dropping tests that can't be evaluated from the flake checks output.

mightyiam

I totally get that this whole change does not affect users.

Well, here are some changes. Please let me know whether I missed anything.

mightyiam · 2026-05-15T15:09:44Z

    devshell = {
      url = "github:numtide/devshell";
-      inputs.nixpkgs.follows = "dev-nixpkgs";
+      flake = false;


Exposes a vanilla /flake-module.nix, so we're good.

mightyiam · 2026-05-15T15:10:07Z

      url = "github:cachix/git-hooks.nix";
-      inputs.nixpkgs.follows = "dev-nixpkgs";
-      inputs.flake-compat.follows = "flake-compat";
+      flake = false;


Exposes a vanilla /flake-module.nix, so we're good.

mightyiam · 2026-05-15T15:17:07Z

    home-manager = {
      url = "github:nix-community/home-manager";
-      inputs.nixpkgs.follows = "dev-nixpkgs";
+      flake = false;


Provides a /lib/default.nix that takes { inherit lib; } so we're golden.

mightyiam · 2026-05-15T15:20:26Z

    treefmt-nix = {
      url = "github:numtide/treefmt-nix";
-      inputs.nixpkgs.follows = "dev-nixpkgs";
+      flake = false;


Provides a vanilla /flake-module.nix so we're golden.

mightyiam · 2026-05-15T15:34:20Z

-    flake-compat.url = "github:NixOS/flake-compat";
+    flake-compat = {
+      url = "github:NixOS/flake-compat";
+      flake = false;


As @MattSturgeon pointed, flake-compat instructs declaring it with flake=false in its readme.

mightyiam · 2026-05-15T15:39:43Z

    # keep-sorted start block=yes newline_separated=yes
    devshell = {
      url = "github:numtide/devshell";
-      inputs.nixpkgs.follows = "dev-nixpkgs";


I've added that single comment above the inputs attribute.

I've pointed out in this PR for each flake=false why it is okay.

I think that projects that expose truly loose files such as /flake-module.nix and /lib/default.nix are aware that users will use them and are not likely to turn them into functions that first take local context such as flake inputs. I prefer this risk over lockfile drift.

mightyiam · 2026-05-15T15:40:47Z

    nix-darwin = {
      url = "github:lnl7/nix-darwin";
-      inputs.nixpkgs.follows = "dev-nixpkgs";
+      flake = false;


Provides a vanilla /eval-config.nix so we're golden.

mightyiam · 2026-05-15T15:44:28Z

+      { config, ... }:
+      {
+        nixpkgs = {
+          source = self.inputs.dev-nixpkgs;


I'll assume you are correct about what we should be doing, but in main, the nix-darwin input has inputs.nixpkgs.follows = "dev-nixpkgs";. Would you like a separate PR that changes that?

mightyiam commented May 15, 2026

View reviewed changes

mightyiam marked this pull request as ready for review May 15, 2026 07:10

MattSturgeon reviewed May 15, 2026

View reviewed changes

mightyiam force-pushed the dev-inputs-flake-false branch 2 times, most recently from 6c4c27f to d0b625b Compare May 15, 2026 15:31

mightyiam commented May 15, 2026

View reviewed changes

mightyiam added 7 commits May 16, 2026 15:54

flake/dev: devshell flake=false

60aef07

flake/dev: git-hooks flake=false

201631b

flake/dev: home-manager flake=false

0566e39

flake/dev: nix-darwin flake=false

3b64bc6

flake/dev: treefmt-nix flake=false

27ab16a

flake/dev: flake-compat flake=false

7b80211

flake/dev: comment about flake=false

4d35f4d

mightyiam force-pushed the dev-inputs-flake-false branch from d0b625b to 4d35f4d Compare May 16, 2026 09:01

mightyiam requested a review from MattSturgeon May 16, 2026 09:02

	inherit (import (self.inputs.home-manager + "/lib") { inherit lib; })
	hmLib = import (self.inputs.home-manager + "/lib") { inherit lib; };
	inherit (hmLib)

Uh oh!

Conversation

mightyiam commented May 15, 2026

Uh oh!

mightyiam left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MattSturgeon May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MattSturgeon commented May 15, 2026

Uh oh!

MattSturgeon commented May 15, 2026

Uh oh!

mightyiam left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MattSturgeon May 15, 2026 •

edited

Loading