Nix (Gestor de paquetes)

Introduction to Nix

Fundamental concepts

• Nix (language)
• Nix (package manager)
• Nix store

Tools and applications

• Nix (command)
• NixOS

⤧︎

Disambiguation: Este articulo trata acerca del gestor de paquetes Nix. No confundir con el Ecosistema Nix, el lenguaje Nix o el comando Nix.

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 a 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) that allows for atomic upgrades, rollbacks and concurrent installation of different versions of a package, essentially eliminating dependency hell.

Uso

Instalación

En NixOS, Nix se instala automáticamente.

En otras distribuciones Linux o en macOS, puedes instalar Nix siguiendo la sección de instalación del manual de Nix.

Comandos Nix

Los comandos Nix estan documentados en el manual de referencia de Nix: comandos principales, utilidades y comandos experimentales. Previo a la version 2.0 (lanzada en Febrero 2018) Nix utilizaba comandos diferentes.

Configuracion

En NixOS, Nix se puede configurar mediante la opción nix.

Una instalación standalone de Nix se configura mediante nix.conf (normalmente ubicado en /etc/nix/). Los detalles sobre las opciones disponibles se encuentran en elmanual de referencia de Nix.

También puedes configurar Nix mediante Home Manager, que gestiona entornos declarativos para un único usuario. Para la configuración a nivel de sistema, puedes utilizar System Manager en Linux y nix-darwin en macOS.

Funcionamiento interno

Nix store

↱︎

This section is a candidate for splitting off into a separate article. El almacén de Nix es conceptualmente lo suficientemente independiente como para justificar un artículo separado. For more information, consult the related discussion page.

Los paquetes construidos por Nix se almacenan en el Nix store, que es de solo lectura y normalmente se encuentra en /nix/store. A cada paquete se le asigna una dirección única especificada por un hash criptográfico seguido del nombre y la versión del paquete, por ejemplo /nix/store/nawl092prjblbhvv16kxxbk6j9gkgcqm-git-2.14.1. Estos prefijos contienen el hash de todas las entradas utilizadas durante el proceso de construcción, incluidos los archivos fuente, el árbol completo de dependencias, las opciones del compilador, etc. Esto permite que Nix instale simultáneamente diferentes versiones del mismo paquete e incluso distintas compilaciones de una misma versión, por ejemplo variantes construidas con diferentes compiladores. Al añadir, eliminar o actualizar un paquete, nada se elimina del store; en su lugar, los enlaces simbólicos a estos paquetes se agregan, eliminan o modifican en los perfiles.

Limpiando Nix store

Para obtener información sobre la limpieza de Nix store, consulta Manual de NixOS: Capítulo - Limpieza del Nix store.

Corrupción de datos en Nix store

Para obtener información sobre cómo reparar un Nix store corrupto, consulta Manual de NixOS: Capítulo - Corrupción del Nix store.

Nombres válidos en Nix store

Main article: Valid Nix store path names

Perfiles

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 /nix/var/nix/profiles, which are in turn symlinked to the user's ~/.nix-profile.

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 fetch* 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).

Sandboxing is enabled by default on Linux, and disabled by default on macOS. In pull requests for Nixpkgs people are asked to test builds with sandboxing enabled (see Tested using sandboxing in the pull request template) because in official Hydra builds sandboxing is also used.

To configure Nix for sandboxing, set sandbox = true in /etc/nix/nix.conf; to configure NixOS for sandboxing set nix.useSandbox = true; in configuration.nix. The nix.useSandbox option is true by default since NixOS 17.09.

Alternative Interpreters

There is an ongoing effort to reimplement Nix, from the ground up, in Rust.

• tvix

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.

• lix

Earlier attempts can be found on riir-nix