two more paraph

src/posts/general_nix/post_packaging/packaging.nix

@@ -0,0 +1,42 @@
+{
+  description = "An flake to provide dev and build environnement for presenterm post production";
+
+  inputs.nixpkgs.url = "https://flakehub.com/f/NixOS/nixpkgs/0.1";
+
+  outputs = inputs: {
+    devShells = forEachSupportedSystem ( { pkgs }: {
+        default = pkgs.mkShell {
+          packages = with pkgs; [
+            presenterm
+            python313Packages.weasyprint
+          ];
+        };
+      } );
+
+    packages = forEachSupportedSystem ( { pkgs }: {
+        default = pkgs.stdenv.mkDerivation {
+          inherit (pkgs) system;
+          name = "linkedin-shoblog-posts";
+          src = ./src;
+          buildInputs = with pkgs; [
+            presenterm
+            python313Packages.weasyprint
+          ];
+          buildPhase =
+            let
+              font_dir = pkgs.nerd-fonts.jetbrains-mono;
+              config = pkgs.writeTextFile {
+                name = "presenterm.conf";
+                text = ''
+                  # presenterm configuration
+                '';
+              };
+            in
+            ''
+              export PRES_CONFIG=${config}
+              python scripts/build.py
+            '';
+        };
+      } );
+  };
+}

src/posts/general_nix/post_packaging/post_packaging.md

@@ -0,0 +1,152 @@
+---
+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".  
+Un soucis de cette approche, c'est que le type du retour de notre fonction n'est pas
+specialement definis, on pourrai avoir un package comme ici, mais aussi une shell avec
+mkShell, ou un host dans le cas d'une configuration nixos. Le seul moyen de le savoir,
+c'est d'avoir une semantique propre sur ses noms de fichiers. De meme, les outils autour
+de nix vont s'attendre a un certain type de retour, mais vont quand meme builder la derivation
+avant de pouvor determiner celui-ci. Par exemple, nix-shell vas s'attendre a avoir le resultat
+d'un mkShell pour fonctionner, mais n'aura pas de moyen de le savoir avant d'avoir interpreter
+la fonction fournis.  
+C'est ainsi que pour resoudre ce probleme d'uniformitee (et quelques autres raisons), les **flakes**
+on ete mis en place.
+<!-- pr:end_slide -->
+les flakes c'est quoi ?
+===
+```nix
+{
+  description = "";
+  inputs = {};
+  outputs = inputs: {};
+}
+```
+Simplement, un flake est un dossier dans lequel se trouve un fichier `flake.nix`
+contenant un attribut set avec les attributs suivants:
+* `description`: la description de ce que fait le flake.
+* `inputs`: un attribut set contenant les dependences du flake, typiquement une instance
+de nixpkgs. Classiquement, chaque input est un repo contenant un autre flake, sur github,
+gitlab ou en local et peut etre pin sur une branche ou un commit specifique.
+* `outputs`: une fonction avec pour parametre le resultat de l'interpretation des inputs
+et retournant un attribut set ou chaque attribut est un resultat possible retourne par
+notre flake, bien qu'il existe des attributs standard utiliser par les outils de nix
+(nix build, nix shell, nix develop), le developpeur est libre de retourner ce qu'il veut,
+ce qui permet a des outils comme *colmena* de creer leur propre standards.
+Pour un package, on vas ainsi retrouver l'attribut `packages.<architecture>.<paquet>` indiquant
+que le flake peut fournir un ou plusieurs packages pour une architecture donnee.
+Ainsi, le flake suivant
+```nix
+{
+  description = "un flake d'exemple";
+  inputs = {
+    nixpkgs.url = "github:nixos/nixpkgs/nixos-25.05";
+  };
+  outputs = inputs: {
+    packages."x86_64-linux".default =
+      with import inputs.nixpkgs {system = "x86_64-linux";};
+      writeShellScriptBin "hello" "echo 'world hello'";
+  }
+}
+```
+