Quand et comment utiliser default.nix, shell.nix et release.nix?

Question

L'un des premiers types de Nix expression que l'on rencontre lors de l'apprentissage de la façon d'utiliser le Nix gestionnaire de paquets est - default.nix; sur la merveilleuse NixOS canal IRC, j'ai appris l'existence d' shell.nix et release.nix ainsi.

J'ai eu l'impression que - à peu près -default.nix doit être utilisé avec nix-build simplement pour la construction du paquet, shell.nix est utilisé avec nix-shell créer un environnement interactif avec le package et l' release.nix est utilisé avec nixops dans le déploiement du package.

Puisque c'est probablement incomplète et partiellement erronée, et depuis, cela ne semble pas être clairement documentée, je voudrais une explication claire et précise de ces sortes de "fichiers standard"; en particulier, pour chacun de ces types de fichiers (ainsi que tous les autres fichiers standard, je suis absent), je voudrais savoir:

1. Quels sont les cas d'utilisation typique pour un tel dossier? Que doit-il pas être utilisé?
2. Comment est ce type de fichier structuré en général? Quelles sont les exigences minimales pour elle?
3. Pourriez-vous montrer un paradigme exemple d'un tel fichier à l'intérieur de son contexte d'utilisation, c'est à dire avec les instructions d'utilisation et y compris les lignes de code nécessaires à une utilisation dans le shell ou d'une autre Nix expression?

Comme un bonus supplémentaire à la question, je veux savoir ce qui - si l'un de ces fichiers standard doit être utilisé lors de l'installation d'un paquet dans un NixOS module? Comment pourrait-il être fait?

Answer 1

Tout d'abord, default.nix et shell.nix ont des significations spéciales en Nix outil, mais release.nix est une commodité une.

Ensuite, default.nix est utilisé comme un fichier par défaut lors de l'exécution d' nix-build, et shell.nix est utilisé comme un fichier par défaut lors de l'exécution d' nix-shell. Comme vous l'avez dit.

Ensuite, default.nix n'est pas utilisé seulement pour nix-build. Par exemple, <nixpkgs/lib/default.nix> est utilisé comme agrégateur pour les fonctions, et ne contiennent pas de dérivations. Donc pas chaque default.nix est censé être "construit" (mais si default.nix est un ensemble d'attributs de dérivations, il va être constructible, et nix-build va construire tous d'entre eux).

Ensuite, nix-shell vont utiliser default.nix si pas d' shell.nix est constaté.

Ensuite, default.nix est utilisé comme fichier par défaut lors de l'importation de l'annuaire. Donc si vous écrivez x = import ./some/directory;, alors ./some/directory/default.nix seront importés. Qui en fait devrait expliquer pourquoi, "nix-build ." utilise default.nix.

Et enfin, il y a deux formats communs pour dérivations en default.nix: dérivation, et callPackage de dérivation. Vous ne pouvez pas nix-build le dernier. Presque n'importe quel paquet dans nixpkgs qui est écrit dans ce style, voir hello. Mais vous pouvez nix-build -E 'with import <nixpkgs> { }; callPackage ./path/to/default.nix { }' comme une solution de contournement. nix-shell prend également en charge cette -E argument.

Answer 2

Comme dit par @danbst seulement default.nix et shell.nix ont une signification particulière pour l'ondine de l'outillage, de qui il n'y a pas de véritable standard et tout le monde est libre d'utiliser ce qui convient le plus à leurs besoins.

Cela dit, cela ne signifie pas que vous ne pouvez pas définir votre propre ensemble de règles, personnellement, pour une seule dérivation projet, j'ai souhaité organiser nix fichiers de la manière suivante:

• default.nix: Utiliser callpackage à l'importation derivation.nix.
• derivation.nix: nixpkgs style de dérivation de fichier.
• shell.nix: nix-fichier shell.
• module.nix: NixOS module fichier, importer default.nix.
• test.nix: NixOS fichier de test.
• release.nix: Hydra jobset déclaration.

Nous avons eu une discussion sur ce sujet au Tokyo NixOS meetup, un exemple d'un tel code de l'organisation peut être trouvé ici.