nix by design↗A different way to Linux.
YOUR JOURNEY
03 / 18
01 — NIX FUNDAMENTALS 5 MIN READ
LESSON 03 / INSIDE THE NIX STORE

Same machine.
Room for both.

Packages have their own addresses, so versions can coexist.

Instead of overwriting a shared library in place, Nix adds a new store object. Existing packages keep referring to their original dependencies.

Explore the lesson
~$ Build your understanding, one idea at a time.
THE NIX MODEL01 / 03
Drag to rotate

App A points to one specific library path.

app A → library v1
03.1 — AN ADDRESS FOR EACH BUILD

The store is an inventory,
not a global bin directory.

Store objects usually live beneath /nix/store. Their paths contain a digest and a human-readable name. The digest is an identifier; for conventional input-addressed derivations it reflects the build inputs, not simply a hash of the final output bytes.

The paths shown below are schematic: real digests are longer. Never rename or edit a store path by hand. Nix treats completed objects as immutable.

store layout · schematic
/nix/store/<digest-a>-my-app-1.0
/nix/store/<digest-b>-library-1.0
/nix/store/<digest-c>-library-2.0
Next section: Profiles connect the pieces.
03.2 — HOW YOUR SHELL FINDS IT

Profiles connect the pieces.

A profile exposes selected packages through a tree of symbolic links. Your PATH points into that environment, so you can type a command normally while its actual executable lives in the store.

Dependencies can be shared when they refer to the same store path. The store does not require a full duplicate of every dependency for every application. The reachable set of dependencies is called a closure.

TAKE THIS WITH YOU

A package keeps its specific dependencies; a new version does not overwrite the old one.

Go a little deeperStore paths in the Nix manual
UP NEXT

Your first Nix shell

Borrow a package for one shell session.

Next lesson