Nix (package manager): Difference between revisions

imported>Ixxie
imported>Ixxie
Retitles sandbox section and removed stub header.
Line 1: Line 1:
{{Expansion|This article is incomplete.}}


Nix is a package manager and build system that parses reproducible build instructions specified in the [[Nix Expression Language]], a pure functional language with lazy evaluation. Nix expressions are pure functions taking dependencies as arguments and producing ''derivation'' specifying a reproducible build environment for the package. Nix stores the results of the build in unique addresses specified by a hash of the complete dependence tree, creating an immutable package store that allows for atomic upgrades, rollbacks and concurrent installation of different versions of a package, essentially eliminating [https://en.wikipedia.org/wiki/Dependency_hell|dependency hell].  
Nix is a package manager and build system that parses reproducible build instructions specified in the [[Nix Expression Language]], a pure functional language with lazy evaluation. Nix expressions are pure functions taking dependencies as arguments and producing ''derivation'' specifying a reproducible build environment for the package. Nix stores the results of the build in unique addresses specified by a hash of the complete dependence tree, creating an immutable package store that allows for atomic upgrades, rollbacks and concurrent installation of different versions of a package, essentially eliminating [https://en.wikipedia.org/wiki/Dependency_hell|dependency hell].  
Line 90: Line 89:
In order to construct a coherent user or system environment, Nix symbolically entries of the Nix store into ''profiles''. These are the front-end by which Nix allows rollbacks: since the store is immutable and previous versions of profiles are kept, reverting to an earlier state is simply a matter of change the symlink to a previous profile. To be more precise, Nix symlinks binaries into entries of the Nix store representing the user environments. These user environments are then symlinked into labeled profiles stored in <code>/nix/var/nix/profiles</code>, which are in turn symlinked to the user's <code>~/.nix-profile</code>.
In order to construct a coherent user or system environment, Nix symbolically entries of the Nix store into ''profiles''. These are the front-end by which Nix allows rollbacks: since the store is immutable and previous versions of profiles are kept, reverting to an earlier state is simply a matter of change the symlink to a previous profile. To be more precise, Nix symlinks binaries into entries of the Nix store representing the user environments. These user environments are then symlinked into labeled profiles stored in <code>/nix/var/nix/profiles</code>, which are in turn symlinked to the user's <code>~/.nix-profile</code>.


=== Sandbox builds ===
=== Sandboxing ===


When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of <code>fetch*</code> functions and files outside the Nix store.  Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see [https://nixos.org/nix/manual/#sec-conf-file nix.conf section] in the Nix manual for details.
When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of <code>fetch*</code> functions and files outside the Nix store.  Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see [https://nixos.org/nix/manual/#sec-conf-file nix.conf section] in the Nix manual for details.