Wanneer en hoe moeten default.nix, shell.nix en release.nix worden gebruikt?

Een van de eerste typen Nix-expressies die je tegenkomt als je de Nix-pakketbeheerder leert gebruiken, is default.nix; op het geweldige NixOS IRC-kanaal hoorde ik ook van het bestaan ​​van shell.nixen release.nix.

Ik heb de indruk dat – ruwweg –default.nixmoet worden gebruikt met nix-buildvoor het eenvoudig bouwen van het pakket, shell.nixwordt gebruikt met nix-shellom een ​​interactieve omgeving met het pakket te creëren en release.nixwordt gebruikt met nixopsbij het implementeren van het pakket.

Aangezien dit waarschijnlijk onvolledig en gedeeltelijk onjuist is, en aangezien dit niet duidelijk gedocumenteerd lijkt te zijn, zou ik graag een duidelijke en nauwkeurige uitleg krijgen van dit soort “standaardbestanden”; in het bijzonder voor elk van deze bestandstypen(evenals alle andere standaardbestanden die ik mis), zou ik graag willen weten:

1. Wat zijn de typische gebruiksscenario’s voor een dergelijk bestand? Waar moeten ze nietvoor worden gebruikt?
2. Hoe is dit bestandstype doorgaans gestructureerd? Wat zijn de minimale vereisten ervoor?
3. Kun je een paradigmavoorbeeld van zo’n bestand binnen zijn gebruikscontextlaten zien, d.w.z. met gebruiksinstructies en inclusief regels code die nodig zijn om het in de shell of een andere Nix-expressie te gebruiken?

Als extra bonusvraag wil ik weten welke – indien aanwezig – van deze standaardbestanden moeten worden gebruikt bij het installeren van een pakket in een NixOS-module? Hoe zou dat gebeuren?

Antwoord 1, autoriteit 100%

Allereerst hebben default.nixen shell.nixeen speciale betekenis in de Nix-tool, maar release.nixis een handige. .

Vervolgens wordt default.nixgebruikt als een standaardbestand bij het uitvoeren van nix-builden wordt shell.nixals standaard gebruikt bestand bij het uitvoeren van nix-shell. Precies zoals je zei.

Vervolgens wordt default.nixniet alleen gebruikt voor nix-build. Bijvoorbeeld <nixpkgs/lib/default.nix>wordt gebruikt als aggregator voor functies en bevat geen afleidingen. Dus niet elke default.nixmoet worden “gebouwd” (maar als default.nixeen attributenset van afleidingen is, kan deze worden gebouwd en nix-buildzal ze allemaal bouwen).

Vervolgens nix-shellzaldefault.nixgebruiken als er geen shell.nixwordt gevonden.

Vervolgens wordt default.nixgebruikt als standaardbestand bij het importeren van de directory. Dus als je x = import ./some/directory;schrijft, dan wordt ./some/directory/default.nixgeïmporteerd. Dat zou eigenlijk moeten verklaren waarom "nix-build ."default.nixgebruikt.

En tot slot zijn er twee veelvoorkomende indelingen voor afleidingen in default.nix: afleiding en callpackage-afleiding. Je kunt de laatste niet nix-build. Vrijwel elk pakket in nixpkgs is in deze stijl geschreven, zie hello. Maar je kan

nix-build -E 'with import <nixpkgs> { }; callPackage ./path/to/default.nix { }'

als een oplossing. nix-shellondersteunt ook dit -Eargument.

Antwoord 2, autoriteit 89%

Zoals gezegd door @danbst hebben alleen default.nixen shell.nixeen speciale betekenis voor de nix-tooling, daarbuiten is er geen echte standaard en is iedereen vrij om te gebruiken wat het beste bij hun behoeften past.

Dat gezegd hebbende, betekent dit niet dat je niet je eigen set regels kunt instellen, persoonlijk wil ik voor een enkel afleidingsproject nix-bestanden op de volgende manier ordenen:

• default.nix: gebruik callpackageom derivation.nixte importeren.
• derivation.nix: afleidingsbestand in nixpkgs-stijl.
• shell.nix: nix-shell-bestand.
• module.nix: NixOS-modulebestand, importeer default.nix.
• test.nix: NixOS-testbestand.
• release.nix: Hydra-taaksetaangifte.

We hadden een gesprek over dit onderwerp tijdens de Tokyo NixOS-meetup, een voorbeeld van een dergelijke code-organisatie is te vinden hier.