Flakes can now refer to other flakes in the same repository using relative paths, e.g.
inputs.foo.url = "path:./foo";
uses the flake in the foo subdirectory of the referring flake. For more information, see the documentation on the path flake input type.
This feature required a change to the lock file format. Previous Nix versions will not be able to use lock files that have locks for relative path inputs in them.
Flake lock file generation now ignores local registries #12019
When resolving indirect flake references like nixpkgs in flake.nix files, Nix will no longer use the system and user flake registries. It will only use the global flake registry and overrides given on the command line via --override-flake.
This avoids accidents where users have local registry overrides that map nixpkgs to a path: flake in the local file system, which then end up in committed lock files pushed to other users.
In the future, we may remove the use of the registry during lock file generation altogether. It’s better to explicitly specify the URL of a flake input. For example, instead of
The nix copy command now has flags --profile and --out-link, similar to nix build. --profile makes a profile point to the
top-level store path, while --out-link create symlinks to the top-level store paths.
For example, when updating the local NixOS system profile from a NixOS system closure on a remote machine, instead of
The advantage is that this avoids a time window where path is not a garbage collector root, and so could be deleted by a concurrent nix store gc process.
The nix-instantiate --eval command now supports a --raw flag, when used
the evaluation result must be a string, which is printed verbatim without
quotation marks or escaping.
Improved NIX_SSHOPTS parsing for better SSH option handling #5181#12020
The parsing of the NIX_SSHOPTS environment variable has been improved to handle spaces and quotes correctly. Previously, incorrectly split SSH options could cause failures in commands like nix-copy-closure, especially when using complex SSH invocations such as -o ProxyCommand="ssh -W %h:%p ...".
This change introduces a shellSplitString function to ensure that NIX_SSHOPTS is parsed in a manner consistent with shell behavior, addressing common parsing errors.
Previously I was able to update the inputs from relatively imported flake.nix inside a monorepo by either:
$ nix flake update basic-go-web-app
or by using --override-input basic-go-web-app ./services/basic-go-web-app/ in the nixos-rebuild to always follow the latest changes from the local second flake file and bypassing the lock file.
Now when I use either of them it fails to run:
$ nix --version
nix (Nix) 2.26.0
$ nix flake update basic-go-web-app
warning: Git tree '/Users/onnimonni/Projects/example-nixos-server' is dirty
warning: updating lock file '"/Users/onnimonni/Projects/example-nixos-server/flake.lock"':
• Updated input 'basic-go-web-app':
'path:./services/basic-go-web-app/?lastModified=1&narHash=sha256-u/7nvhOP4IIccK8AFuBtd529fC5163IjyBfv6z5GRUE%3D' (1970-01-01)
→ 'path:./services/basic-go-web-app/'
warning: Git tree '/Users/onnimonni/Projects/example-nixos-server' is dirty
$ git diff flake.lock
diff --git a/flake.lock b/flake.lock
index 9509062..f41dc51 100644
--- a/flake.lock
+++ b/flake.lock
@@ -6,15 +6,14 @@
"go-nixpkgs": "go-nixpkgs"
},
"locked": {
- "lastModified": 1,
- "narHash": "sha256-u/7nvhOP4IIccK8AFuBtd529fC5163IjyBfv6z5GRUE=",
"path": "./services/basic-go-web-app/",
"type": "path"
},
"original": {
"path": "./services/basic-go-web-app/",
"type": "path"
- }
+ },
+ "parent": []
},
"disko": {
"inputs": {
$ nix run nixpkgs#nixos-rebuild -- switch --fast --flake .#rusty --target-host rusty --build-host rusty --use-remote-sudo
building the system configuration...
warning: Git tree '/Users/onnimonni/Projects/example-nixos-server' is dirty
error:
… while updating the lock file of flake 'git+file:///Users/onnimonni/Projects/example-nixos-server'
error: lock file contains unlocked input '{"path":"./services/basic-go-web-app/","type":"path"}'
What is the correct way to update the relative flake import?
I wasted my Saturday trying to get a relative flake import working in my nixos config. What a nice coincidence to see that fix included in this release! So I just run nix flake update on my nixos system to get these updates?
Yes, meson emits compile_commands.json in the build directory, and clangd picks that up.
So that’s just calling mesonConfigurePhase in the dev shell, and you’re set up.
We bundle a clangd in nix develop .#native-clangStdenv. I then use the vscode direnv extension to make that available to the clangd extension.
my .envrc
This could probably be done way simpler. I haven’t really changed it in ages.
watch_file flake.nix
watch_file flake.lock
# nixEnv="$(nix print-dev-env)"
nixEnv="$(nix print-dev-env .#native-clangStdenv)"
# nixEnv="$(nix print-dev-env .#hydraJobs.buildNoGc.i686-linux)"
if [[ -z $nixEnv ]]
then use_nix
else
HOST_XDG_DATA_DIRS="${XDG_DATA_DIRS:-}"
eval "${nixEnv:-}"
export XDG_DATA_DIRS="${XDG_DATA_DIRS}:${HOST_XDG_DATA_DIRS}"
fi
Oh well, that’s a bit of an anti-feature for me. I had hoped for having a system flake that would register itself (at it’s specific version) in local registry and a couple of task-specific flakes that would refer to it via local registry and define shell with some task-specific software. Rationale: keeping different source flakes versions in sync would be so much easier.
I know I’d face some problems with flake.lock in task-flakes, but a forced update (or rm flake.lock) would probably sort that out and still keep all task-flakes refer to the same nixpkgs. Effectively I want a shared flake.lock between several flakes.
Any ideas I can achieve this now? Running nix flake update at exactly the same time for all task-flakes or manually fiddling with flake.lock seem a no-go for me. So does having task-flakes refer to nixpkgs at different points of time and thus installing several versions of whatever lib out there. Building stuff locally instead of substituting it seems fine, at least for the task-flakes.