nix nixos nixops

¿Cuándo y cómo se deben usar default.nix, shell.nix y release.nix?



nixos nixops (2)

Uno de los primeros tipos de expresiones de Nix que se encuentran al aprender a usar el administrador de paquetes Nix es default.nix ; En el maravilloso canal de IRC de NixOS también me enteré de la existencia de shell.nix y shell.nix .

Tengo la impresión de que, aproximadamente, default.nix se utilizará con nix-build para nix-build simplemente el paquete, shell.nix se usa con nix-shell para crear un entorno interactivo con el paquete y release.nix se usa con nixops en la implementación del paquete.

Como es probable que esto sea incompleto y parcialmente incorrecto, y dado que esto no parece estar claramente documentado, me gustaría una explicación clara y precisa de este tipo de "archivos estándar"; en particular, para cada uno de estos tipos de archivos (así como cualquier otro archivo estándar que me falte), me gustaría saber:

  1. ¿Cuáles son los casos de uso típicos de un archivo de este tipo? ¿Para qué no deben usarse?
  2. ¿Cómo se estructura este tipo de archivo normalmente? ¿Cuáles son los requisitos mínimos para ello?
  3. ¿Podría mostrar un ejemplo paradigmático de tal archivo dentro de su contexto de uso , es decir, con instrucciones de uso e incluyendo líneas de código necesarias para usarlo en el shell o en otra expresión de Nix?

Como una pregunta adicional, quiero saber cuál de estos archivos estándar, si alguno, debería usarse al instalar un paquete en un módulo NixOS. ¿Cómo se haría eso?

Como lo dijo @danbst, solo default.nix y shell.nix tienen significados especiales para las herramientas de shell.nix , de ahí que no haya un estándar real y que todos puedan usar lo que mejor se adapte a sus necesidades.

Dicho esto, no significa que no pueda establecer su propio conjunto de reglas, personalmente para un proyecto de derivación única. Me gusta organizar los archivos nix de la siguiente manera:

  • default.nix : use el callpackage de callpackage para importar derivation.nix .
  • derivation.nix : archivo de derivación de estilo nixpkgs.
  • shell.nix : archivo nix-shell.
  • module.nix : archivo de módulo NixOS, import default.nix .
  • test.nix : archivo de prueba NixOS.
  • release.nix : declaración de trabajo Hydra.

Tuvimos una charla sobre este tema en la reunión de Tokyo NixOS, se puede encontrar un ejemplo de una organización de código de este tipo here .

En primer lugar, default.nix y shell.nix tienen significados especiales en la herramienta Nix, pero release.nix es conveniente.

A continuación, default.nix se utiliza como archivo predeterminado cuando se ejecuta nix-build , y shell.nix se usa como archivo predeterminado cuando se ejecuta nix-shell . Justo como dijiste.

A continuación, default.nix no se usa solo para nix-build . Por ejemplo, <nixpkgs/lib/default.nix> se usa como agregador para funciones, y no contiene derivaciones. Por lo tanto, no se supone que todos los default.nix estén "construidos" (pero si default.nix es un conjunto de atributos de derivaciones, se podrán nix-build , y nix-build los construirá todos).

A continuación, nix-shell usará default.nix si no se encuentra shell.nix .

A continuación, se utiliza default.nix como archivo predeterminado al importar el directorio. Así que si escribes x = import ./some/directory; , luego ./some/directory/default.nix será importado. Eso en realidad debería explicar por qué "nix-build ." utiliza default.nix .

Y, finalmente, hay dos formatos comunes para derivaciones en default.nix : derivación y derivación de callPackage . No puedes nix-build este último. Casi cualquier paquete en nixpkgs está escrito en este estilo, vea hello . Pero puedes nix-build -E ''with import <nixpkgs> { }; callPackage ./path/to/default.nix { }'' nix-build -E ''with import <nixpkgs> { }; callPackage ./path/to/default.nix { }'' como solución alternativa. nix-shell también soporta este argumento -E .