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<ref>Values cannot change during computation. Functions always produce the same output if their input does not change. </ref>taking dependencies as arguments and producing a ''[[Derivations|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 dependency tree, creating an immutable package store (aka the [[#Nix store|nix 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].
NixOS: Nix is being installed while you install NixOS.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Installation"></span>
If you intend to utilize Nix on a different Linux distribution or a Mac computer, you can perform a standalone installation: The [https://nixos.org/manual/nix/stable/installation/installation installation section of the Nix manual] describes the installation of standalone Nix from binary or source.
The [[Nix command|Nix commands]] are documented in the [https://nixos.org/manual/nix/stable/command-ref/command-ref Nix reference manual]: main commands, utilities and experimental commands. Prior to version 2.0 (released in February 2018) there have been different commands.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Nix_commands"></span>
=== Configuration ===
=== Nix 命令 ===
On NixOS, Nix is configured through the [https://search.nixos.org/options?query=nix. <code>nix</code> option].
Standalone Nix is configured through <code>nix.conf</code> (usually found in <code>/etc/nix/</code>), which defines a number of settings relating to evaluation, builds, garbage collection, sandboxing, and user permissions. Details on the available options are [https://nixos.org/manual/nix/stable/command-ref/conf-file found in the Nix reference manual].
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Configuration"></span>
Even further configuration is possible with [[Home Manager]] to manage declarative environments for a single user. For system-wide configuration on Linux, you can use [https://github.com/numtide/system-manager System Manager]. For system-wide configuration on macOS, [https://github.com/LnL7/nix-darwin nix-darwin] is the preferred solution.
你也可以使用 [[Home Manager|Home Manager]] 配置 Nix，它为单用户提供管理声明式环境的能力。对于系统范围的配置，可以在 Linux 上使用 [https://github.com/numtide/system-manager System Manager]，在 macOS 上使用 [https://github.com/nix-darwin/nix-darwin nix-darwin]。
<span id="Internals"></span>
== 内部机制 ==
<div lang="en" dir="ltr" class="mw-content-ltr">
=== Nix store ===
=== Nix store ===
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
{{Split|reason=Nix store 在概念上有足够的独立性，值得单独成文。}}
Packages built by Nix are placed in the read-only ''Nix store'', normally found in <code>/nix/store</code>. Each package is given a unique address specified by a cryptographic hash followed by the package name and version, for example <code>/nix/store/nawl092prjblbhvv16kxxbk6j9gkgcqm-git-2.14.1</code>. These prefixes hash all the inputs to the build process, including the source files, the full dependency tree, compiler flags, etc. This allows Nix to simultaneously install different versions of the same package, and even different builds of the same version, for example variants built with different compilers. When adding, removing or updating a package, nothing is removed from the store; instead, symlinks to these packages are added, removed or changed in ''profiles''.
In order to construct a coherent user or system environment, Nix symlinks 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>.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Sandboxing"></span>
=== Sandboxing ===
=== 沙盒 ===
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
启用沙盒构建后，Nix 将为每个构建过程设置一个隔离环境。这用于移除构建环境中的的其它隐藏依赖项，以提高构建结果的可复现性。这包括在构建过程中对 <code>fetch*</code> 函数之外的网络访问，以及对 Nix Store 之外的文件访问的不可行。根据操作系统的不同，对其他资源的访问也会被阻止（例如，在 Linux 上，进程间通信也是被隔离的）。
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.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
Linux 系统默认启用沙盒，而 macOS 系统则默认禁用沙盒。
Sandboxing is enabled by default on Linux, and disabled by default on macOS.
In pull requests for [https://github.com/NixOS/nixpkgs/ Nixpkgs] people are asked to test builds with sandboxing enabled (see <code>Tested using sandboxing</code> in the pull request template) because in [https://nixos.org/hydra/ official Hydra builds] sandboxing is also used.
To configure Nix for sandboxing, set <code>sandbox = true</code> in <code>/etc/nix/nix.conf</code>; to configure NixOS for sandboxing set <code>nix.useSandbox = true;</code> in <code>configuration.nix</code>. The <code>nix.useSandbox</code> option is <code>true</code> by default since NixOS 17.09.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Alternative_Interpreters"></span>
=== Alternative Interpreters ===
=== 可选的解释器 ===
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
目前正在进行一项计划，从零开始使用 Rust 重新实现 Nix。
There is an ongoing effort to reimplement Nix, from the ground up, in Rust.
There is also a community-led fork of Nix 2.18 named Lix, focused on correctness, usability, and growth. While it has also ported some components of Nix to Rust, it is not a ground-up rewrite like Tvix.
This section is a candidate for splitting off into a separate article. Nix store 在概念上有足够的独立性，值得单独成文。 For more information, consult the related discussion page.
启用沙盒构建后，Nix 将为每个构建过程设置一个隔离环境。这用于移除构建环境中的的其它隐藏依赖项，以提高构建结果的可复现性。这包括在构建过程中对 fetch* 函数之外的网络访问，以及对 Nix Store 之外的文件访问的不可行。根据操作系统的不同，对其他资源的访问也会被阻止（例如，在 Linux 上，进程间通信也是被隔离的）。
Linux 系统默认启用沙盒，而 macOS 系统则默认禁用沙盒。
在 Nixpkgs 的拉取请求中，提交者被要求启用沙盒进行构建测试（请参阅拉取请求模板中的 Tested using sandboxing），因为 官方 Hydra 构建 中也使用了沙盒。
