`builtins.getFlake` accepts `git+file:/home/...` AND `git+file:///home/...` with different semantics #200

New issue

Open

opened 2024-03-29 22:27:14 +00:00 by rbt · 4 comments

rbt commented

2024-03-29 22:27:14 +00:00

Owner

git+file: gets the latest commit and git+file:// gets the changes in the working tree. What the hell.

nix-repl> (builtins.getFlake "git+file:/Users/wiggles/infrastructure").outPath
"/nix/store/7j7smga3nxq1sn392c863cja4vv5m12l-source"

nix-repl> (builtins.getFlake "git+file:///Users/wiggles/infrastructure").outPath
"/nix/store/hry7m94vcmy3jznf6qyg8k0f4jhyw2dx-source"

`git+file:` gets the latest commit and `git+file://` gets the changes in the working tree. What the hell. ``` nix-repl> (builtins.getFlake "git+file:/Users/wiggles/infrastructure").outPath "/nix/store/7j7smga3nxq1sn392c863cja4vv5m12l-source" nix-repl> (builtins.getFlake "git+file:///Users/wiggles/infrastructure").outPath "/nix/store/hry7m94vcmy3jznf6qyg8k0f4jhyw2dx-source" ```

rbt added the

bug

label

2024-03-29 22:27:14 +00:00

lunaphied commented

2024-03-29 22:31:13 +00:00

Owner

Please test this on upstream unstable and report if the same behavior happens; I noticed these seemed to possibly change behavior on later versions and want to decide an approach to take.

Also note that in certain contexts git+file:. and "git+file://" + (toString ./.) also work, so it'd be interesting to see how they compare

Please test this on upstream unstable and report if the same behavior happens; I noticed these seemed to possibly change behavior on later versions and want to decide an approach to take. Also note that in certain contexts `git+file:.` and `"git+file://" + (toString ./.)` also work, so it'd be interesting to see how they compare

jade commented

2024-03-29 23:12:33 +00:00

Owner

This was found on Nix 2.21 according to wiggles (here with me).

jade added the

Area/flakes

label

2024-03-30 00:04:22 +00:00

kfearsoff commented

2024-11-11 16:03:55 +00:00

Member

This was recently reported again in Lix Matrix: https://matrix.to/#/!9IQChSjwSHXPPWTa:lix.systems/$QbdSBiz-aDQOBKeRkNoJTNn7n69mP8Q-Kk9Yg-kt-rY?via=lix.systems&via=matrix.org&via=catgirl.cloud

I checked CppNix 2.18 manual and apparently, it is documented behavior: https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-flake#types

git+file in general seems very cursed, it has different lockfile fields, for example. And this line scares me:

If there are uncommitted changes, the reference is treated as dirty and a warning is printed.

This is the behavior that you get when you clone a flake Git repo (e.g. Nixpkgs) and change something in its tree. I fear that the "root" flake (which is a confusing name) implicitly uses git+file without recording the data in the lockfile. This probably explains the god awful "file is not found" error message when you don't stage the changes in git worktree. That sounds like an awful lot of spaghetti to untangle, so it's probably best to not touch it until we are fully ready.

This was recently reported again in Lix Matrix: https://matrix.to/#/!9IQChSjwSHXPPWTa:lix.systems/$QbdSBiz-aDQOBKeRkNoJTNn7n69mP8Q-Kk9Yg-kt-rY?via=lix.systems&via=matrix.org&via=catgirl.cloud I checked CppNix 2.18 manual and apparently, **it is documented behavior**: https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-flake#types `git+file` in general seems very cursed, it has different lockfile fields, for example. And this line scares me: > If there are uncommitted changes, the reference is treated as dirty and a warning is printed. This is the behavior that you get when you clone a flake Git repo (e.g. Nixpkgs) and change something in its tree. I fear that the "root" flake (which is a confusing name) implicitly uses `git+file` without recording the data in the lockfile. This probably explains the god awful "file is not found" error message when you don't stage the changes in git worktree. That sounds like an awful lot of spaghetti to untangle, so it's probably best to not touch it until we are fully ready.

👀 1