YOUR JOURNEY
14 / 18
03THINKING IN FLAKES 6 MIN READ
LESSON 14 / LOCKING THE INPUTS

Moving sources.
Fixed references.

A branch can move. A lock file remembers which revision you used.

Commit both flake.nix and flake.lock so another checkout can resolve the same dependency graph.

Explore the lesson
~$ Hands-on examples · Nix with flakes enabled.
THE FLAKE MODEL01 / 03
Drag to rotate

A branch name initially resolves to a revision.

Branch resolves to revision A
14.1PIN THE GRAPH

Record the choice once.

A URL such as github:NixOS/nixpkgs/nixos-unstable points at a moving branch. The lock file records its resolved revision and content hash, together with other input relationships. Normal use can then reuse those recorded inputs.

Create the lock and inspect what was resolved. In a Git repository, add new flake source files to Git so Nix includes them in the source snapshot.

terminal · project directory
git init
git add flake.nix
nix flake lock
git add flake.lock
nix flake metadata
git commit -m "Add and lock Nix project"
Next section: Treat dependency updates as changes.
14.2UPDATE ON PURPOSE

Treat dependency updates as changes.

Use nix flake update nixpkgs to update that named input. Use nix flake update to update all inputs. Read the diff and rebuild or test your project before committing.

Locking inputs does not guarantee that every build is deterministic or that an input will remain available forever. It makes the source revisions explicit and reviewable.

terminal
nix flake update nixpkgs
git diff -- flake.lock
nix flake check
# After reviewing and testing:
git add flake.lock
git commit -m "Update Nixpkgs input"
TAKE THIS WITH YOU

Keep the lock file in Git; update it as an intentional dependency change.

Go a little deeperUpdating flake inputs
UP NEXT

A shared development shell

Put a development environment next to the project that needs it.

Next lesson