---
options:
  command_prefix: "pr:"
theme:
  name: tokyonight-storm
  override:
    default:
      # colors:
        # foreground: "4c4f69"
        # background: "ffffff"
    code: 
      alignment: center
    palette:
      colors:
        base00: "24283B"
        base01: "16161E"
        base02: "343A52"
        base03: "444B6A"
        base04: "787C99"
        base05: "A9B1D6"
        base06: "CBCCD1"
        base07: "D5D6DB"
        base08: "C0CAF5"
        base09: "A9B1D6"
        base0A: "0DB9D7"
        base0B: "9ECE6A"
        base0C: "B4F9F8"
        base0D: "2AC3DE"
        base0E: "BB9AF7"
        base0F: "F7768E"
---
<!-- LTeX: language=fr -->
presenterm build process with nix
===
```file +line_numbers 
path: packaging.nix
language: nix
```
Hier je me suis dit que j'allais faire un petit repo avec les différents posts de
cette série, histoire de rendre les textes source accessible entre autre pour les
personnes malvoyantes ou juste pour ceux ne souhaitant pas lire des images en 24px * 24px.
Problème, mon cerveau un peu mal fichu, c'est aussi dit "tient, et si tu en profitais
pour faire un flake avec un environnement dev pour qui voudrait preview tes slides
sans avoir à installer presenterm puis "hey mais attend, tu pourrais aussi faire
en sorte de générer un package avec nix qui contient tous les PDF", ce qui inclut
donc de les générer au moment du packaging.  
Et donc après quelques heures de trifouillage, me voici pour vous présenter mes
bêtises.  
Vous connaissez la routine, lancez spotify et c'est parti pour un peu de lecture
# album du jour
## Neo: the world end with you original soundtrack - Takeharu Ishimoto
![](./cover.jpg)
<!-- pr:end_slide -->
OK, comment ça marche ?
===
Avant de parler de ce que sont les flakes et de leur intérêt dans l'écosystème
de nix, commençons par la base, qu'est-ce qu'un package en nix ? "Simplement",
une fonction qui décrit un process de build, pour reprendre les exemples des articles
précédents, pour le packaging des assets de mon site avec **Vue**, nous avons une
fonction prenant en entrée les dépendances nécessaires pour le process de build,
puis décrivant ce dernier, puis retournant uniquement les assets builder sous la
la forme d'un path dans le store nix.  Grossièrement, en terme de code cela donnerais
quelque chose du style:  
```nix
# package.nix
{ pkgs }: pkgs.stdenv.mkDerivation {
  pname = "mon super website";
  version = "3.14";
  src = pkgs.fetchgit {
    url = "http://git.shobu.fr/shoblog/front";
    rev = "069d2a5bfa4c4024063c25551d5201aeaf921cb3";
    sha256 = "sha256-MlqJOoMSRuYeG+jl8DFgcNnpEyeRgDCK2JlN9pOqBWA=";
  };
  buildInputs = with pkgs; [
    node
    yarn
  ];
  buildPhase = ''yarn build'';
  installPHase = ''
    mkdir -p $out/dist
    cp dist $out
  '';
}
```
L'exemple est bien sûr quelque peu simplifié, mais dans les grandes lignes :
* `{ pkgs }: {}`: constitue notre fonction, avec en argument *pkgs* qui correspond
à une instance de nixpkgs.  
* `pkgs.stdenv.mkDerivation`: est la fonction la plus basique nous permettant de créer
un package, les autres fonction, comme mkYarnPackage, étendent cette dernière.
Cette fonction prend elle aussi plusieurs arguments qu'elle vas utiliser pour builder
notre package
  * `pname` et `version`: le nom de notre package et sa version
  * `src`: les fichiers qui serons accessible dans notre environnement de build et
  qui constituent la source de notre package.
  * `buildInputs`: les paquets qui serons accessibles dans notre environnement
  de build.
  * `buildPhase` et `installPhase`: Les hook qui décrivent comment builder et installer
  notre paquet. Il existe d'autre hooks pour d'autre usages décris dans la documentation.

Vous aurez remarqué de votre œil attentif que la fonction s'appelle `mkDerivation`,
et non pas `mkPackage` par exemple comme on aurais pu s'y attendre. Pourquoi ça ?
Dans nix, la dérivation est le bloc fondamental du système de build de nix, un
package n'étant qu'une forme de dérivation. Pour rester simple, je resterais sur
l'appellation plus classique de "package".
