Nixvim's flake keeps updating my flake.lock file

[refaelsh]

I am using the stand alone flake for Nixvim. And I use its output package in systemPackages.
Every time I run sudo nixos-rebuild switch --flake ~/repos/dotfiles/#myNixos my NixOS's flake.lock file get always updated liek this:

diff --git a/flake.lock b/flake.lock
index bf5ca808..116e2f49 100644
--- a/flake.lock
+++ b/flake.lock
@@ -283,11 +283,11 @@
       "locked": {
         "lastModified": 1,
         "narHash": "sha256-Yu5tiYabepl0wGMYe7m5DlV70R4yIgkAyRsf+/Lgyw0=",
-        "path": "/nix/store/c1i7f9j9j75gi39x5dxysiwz9rz9q40y-source/nixvim",
+        "path": "/nix/store/jl19vjcsm4lpn5r8iqgg8zxwihmy657h-source/nixvim",
         "type": "path"
       },
       "original": {
-        "path": "/nix/store/c1i7f9j9j75gi39x5dxysiwz9rz9q40y-source/nixvim",
+        "path": "/nix/store/jl19vjcsm4lpn5r8iqgg8zxwihmy657h-source/nixvim",
         "type": "path"
       }
     },
(END)

Is that normal? I have a feeling its not. What can I do please?

[MattSturgeon]

I suspect this is a result of having your flake input be a relative path?

When you evaluate a flake, the first thing nix does is copy everything in the flake and it's inputs to the nix store. Then the actual work is done in the nix store. That's why when you see errors or warnings, it's always talking about files in /nix/store rather than ~/repos/dotfiles.

What is likely happening here is that the flake input has changed and therefore gets a different store location. I must admit, I thought that'd only happen when you ran nix flake lock, but I guess I was wrong?

My advice would be to always have your inputs point to github: or other similar remote URLs. Using local relative paths should really only be done for ad-hoc testing or debugging and can also be achieved with nix flake lock --override-input instead of editing flake.nix.

If you're trying to keep both flakes in sync, then perhaps they should just be a single flake?

[refaelsh]

Well, I do use a relative path in my inputs. The whole thing is here: https://github.com/refaelsh/dotfiles.
I have a folder called nixvim that contains a stand alone flake of Nixvim
In my NixOS flake I have this:

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    nixvim.url = "./nixvim";
  };

I do indeed use a relative path for the Nixim flake.
I want it this way because:

1. So that I would still be able to nix run my neovim for quick configuration testing.
2. I wanna be able to send to a friend a link to Github with my Nixvim flake and the friend will be able to nix run it.

Can something be done about the constantly auto updating lock file?

[khaneliman]

One note too, from doing a lot of local development input pinning for a while. Is that if you ever have local changes that aren't committed, you wont be able to update the flake lock properly for that input. You need a clean working directory with committed changes.

[refaelsh]

@traxys Understood. Thanks.

[refaelsh]

@khaneliman Good point. Got it. Thanks.

[MattSturgeon]

You can still do this using a single flake, though you will need to do nix run .#<the neovim package name> if you have multiple packages

If you have your nvim package also be your default app or package output, then you still don't need to specify .#<name>, even if it is one of many outputs in a larger flake.

[MattSturgeon]

As this seems to come up a lot, we should probably have an example template where a nixvim configuration and a NixOS configuration are both defined in a single flake.

[refaelsh]

Just curious why you don't just make the input point to that nixvim location on github then?

Now that I have gained more flakes knowledge, I can answer this question.
I have numerous other flakes like Nixvim that are standalone.
Each time I change something in one of them, I need to run nix flake update and this takes a lot of time if nixpkgs was updated upstream. And that why I want relative path for my flakes. I want to run nix flake update vary rarly.

[MattSturgeon]

But is there any particular reason these other flakes need to be standalone? With appropriate naming I don't see why you couldn't have hundreds of packages, configs, etc in one flake.

Flake-parts would probably be useful to keep things organised in separate files/folders though.

[refaelsh]

But is there any particular reason these other flakes need to be standalone?

No real reason. I just like it that way. Purely phycological. I love small self-contained units.

[MattSturgeon]

That's really the purpose of flake-parts; allowing a flake to be broken up into modules, similar to a nixos config.

Although, I also have to wonder what the purpose of the downstream (top-level) flake is in your setup, if the other flakes are truly independent and unrelated to each other?

Is it just doing something like inputs.nixosConfig.nixosConfigurations.foo.extendModules { modules = [ myNixvimModule ]; }?

Having a single flake, with a single lockfile, would simplify your workflow and dependency management. But there's many ways to skin a cat 😁

[refaelsh]

Although, I also have to wonder what the purpose of the downstream (top-level) flake is in your setup

It my NixOS flake.

Is it just doing something like inputs.nixosConfig.nixosConfigurations.foo.extendModules { modules = [ myNixvimModule ]; }?

Exactly that.

Having a single flake, with a single lockfile

Yes, but: No real reason. I just like it that way. Purely phycological. I love small self-contained units :-)