La Forge - nix

Partie 6 : Vers une normalisation des dérivations

2023-05-02T00:00:00+00:00

Les articles de la série

Bonjour à toutes et tous! 😀

Sixième article sur Nix.

Les dérivations pures c’est bien, mais elles donnent un peu trop de liberté.

Absence de standard

Le problème de l’informatique est souvent l’interopérérabilité.

L’interopérabilté est le fait de permettre à deux sytèmes de pouvoir se parler au travers d’un canal normalisé.

Prenons la dérivation de la partie 4 :

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}

Elle complile les sources vers le chemin $out.

Et donc le $out est un exécutable.

A l’inverse, le paquet ${pkgs.bash} a son binaire dans le dossier $out/bin/bash.

Pour coller à ce mode fonctionnement, nous allons devoir modifier quelques peu notre dérivation.

La première est de créer le dossier $out/bin que l’on souhaite devenir la destination du produit de compilation.

On modifie également le paramètre -o $out de gcc en -o $out/bin/hello-world.

On rajoute aussi coreutils dans le PATH pour accéder à la commande mkdir.

nix-shell> with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    mkdir -p $out/bin                       
    gcc $SOURCE -o $out/bin/hello-world         
    ''
  ];
  PATH = "${gcc}/bin:${coreutils}/bin/";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}

This derivation produced the following outputs:
  out -> /nix/store/4wvz6l7l436ma226k4gky9985fanv8cg-hello-world

On peut ainsi visualiser le contenu de la réalisation de la dérivation.

$ tree /nix/store/4wvz6l7l436ma226k4gky9985fanv8cg-hello-world
/nix/store/4wvz6l7l436ma226k4gky9985fanv8cg-hello-world
└── bin
    └── hello-world

On se retrouve bien avec une structure semblable à celle de ${pkgs.bash}/bin/bash.

Inputs

L’intérêt principal de normaliser des manières de faire c’est que l’on peut facilement automatiser.

Par exemple, la définition du PATH.

Si tout les paquets respectent le même schéma de définitions des binaires.

PATH = "{bash}/bin:{gcc}/bin:{coreutils}/bin".

Alors, on peut simplifier l’écriture pour passer par un tableau.

buildInputs = [ bash gcc coreutils ]

Bon très bien, mais il n’y aura pas grand chose qui se passera.

$buildInputs n’est qu’une variable d’environnement.

Nous allons devoir la faire vivre.

Setup

Nous allons établir une stratégie permettant d’utiliser notre variable $buildInputs.

Pour cela, nous allons déterminer un script qui fera le travail à notre place.

Je le défini délibérément naïf, dans la réalité, il faudrait le rendre plus versatile, mais ça suffira pour la démo.

On reset d’abord le $PATH.

Puis on profite de la propriété de la dérivation qui lorsque que l’on l’interpole sous la forme d’une chaîne devient le $out de la dérivation.

Propriété qui fonctionne également avec un tableau.

nix-repl> toString [ bash gcc coreutils ]
"/nix/store/zlf0f88vj30sc7567b80l52d19pbdmy2-bash-5.2-p15 
/nix/store/nlgyw2fv0cm8rkz8qm1jyw78vyif1bl9-gcc-wrapper-12.2.0 
/nix/store/arbxkmcgv9h8pjgj95c6d7r86yb77rl5-coreutils-9.1"

Comme nous avons choisi que les binaires serait dans le dossier $out/bin. Nous pouvons créer notre $PATH automatiquement.

PATH=""
for input in $buildInputs; do
  PATH="$PATH:$input/bin"
done

Nous allons alors faire deux choses:

définir un fichier setup.sh via la même méthode que pour les sources
utiliser la source qui permet d’exécuter le bash contenu dans un fichier

La réunion de ces deux actions nous donnes la dérivation suivante:

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    source $SETUP

    # builder
    mkdir -p $out/bin                       
    gcc $SOURCE -o $out/bin/hello-world         
    ''
  ];

  SETUP = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
    '';

  buildInputs = [ bash gcc coreutils ];

  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}

Cela peut sembler étrange de vouloir écrire plus de lignes pour le même résultat, mais nous sommes en train de nous rapprocher de l’automatisation.

Et nous allons aller encore plus loin !

Builder

Nous allons sortir dans un builder.sh le contenu du build.

mkdir -p $out/bin                       
gcc $SOURCE -o $out/bin/hello-world

Je vais alors définir deux variables:

$setupPhase anciennement $SETUP
$buildPhase le chemin du builder.

Et on rajoute le source builder.sh qui va bien.

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];

  buildPhase = builtins.toFile "builder.sh" ''
    mkdir -p $out/bin
    gcc $SOURCE -o $out/bin/hello-world
  '';

  setupPhase = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
  '';

  buildInputs = [ bash gcc coreutils ];

  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
  '';
}

Ok, et donc, ça nous avance à quoi ?

J’y arrive ^^ ^

Normalisation de la dérivation

Maintenant que nous avons normalisé ce que l’on pouvais, nous allons pouvoir passer à l’automatisation !

Pour cela, nous allons créer une fonction qui va retourner une dérivation.

Mais avant de pouvoir y arriver, nous allons encore manipuler un peu de Nix.

Ne vous plaignez pas c’est pour votre bien. ^^ C’est comme pour aller à l’étranger, savoir commander une bière c’est bien.

Pouvoir également dire en cas d’arrestation: “Je suis français, je voudrai appeler l’Ambassade” dans la langue, c’est mieux ^^

Nous allons donc découvrir d’autres syntaxes de la grammaire.

Paramètres optionels

Lorsque l’on défini une fonction en Nix, nous pouvons lui donner un set en entrée, ce set possède des champs qui sont nommés.

Si notre fonction a pour signature

f = {x, y} : x + y

Il est obligatoire de remplir tous les champs

nix-repl> f {x = 12;}
error: function 'anonymous lambda' called without required argument 'y'

Ici, Nix, nous averti qu’il manque un paramètre.

Bien que cela soit pratique dans certains cas, cela peut être ennuyeux. Car l’obligation de conformité est également contraignante lorsqu’il y a trop de paramètres.

nix-repl> f { x = 12; y = 4; z = 42;}
error: function 'anonymous lambda' called with unexpected argument 'z'

Nix attendait seulement un paramètre x et y. Nous lui avons donné un paramètres ‘z’.

Sauf que parfois, nous ne contrôlons pas avec exactitude les paramètres d’entrées, il peut y avoir les bons champs au bon nom mais avec des des champs supplémentaires.

data = { x = 12; y = 4; z = 42; t = { a = "chat"; b = true; }; }

A l’appel, nous avons sans surprise une erreur.

nix-repl> f data
error: function 'anonymous lambda' called with unexpected argument 'z'

Il est possible de déclarer différement notre fonction pour lui faire accepter des paramètres optionels.

f2 = {x, y, ...} : x + y

Et maintenant ça marche correctement ^^

nix-repl> f2 data
16

Bien entendu, les règles de champs obligatoires restent valides.

nix-repl> f { x = 12; }
error: function 'anonymous lambda' called without required argument 'y'

Et il est également possible de mélanger les concepts de champs par défaut et optionnel.

f3 = { x, y ? 0, ...} : x + y

Et désormais y n’est plus obligatoire.

nix-repl> f3 { x = 12; }
12

Le mot-clef inherit

Il s’agit d’un sucre syntaxique qui permet de ne pas répéter le champ et la valeur lorsque les deux possèdent le même nom.

nix-repl> x = 12
nix-repl> { x = x; }
{ x = 12; }

Est équivalent à

nix-repl> { inherit x; }
{ x = 12; }

Set Binding

J’ai pas trouvé de traduction satisfaisante.

C’est l’idée que l’on puisse récupérer le set dans une variable.

La syntaxe est:

args @ { x = 12; y = true; }

{ x = 12; y = true; } @ args

On peut utiliser cette propriété pour copier les champs dans un set:

wrapping = inner @ {x, y ? 0, ... } : name : 
  { inherit inner; inherit name; }

On peut alors utiliser notre data et lui donner un label.

nix-repl> wrapping data "toto"
{ inner = { ... }; name = "toto"; }

Fusion (merge) de sets

Il est possible de combiner plusieurs sets en un seul.

nix-repl> { x = 12; } // { y = true; }
{ x = 12; y = true; }

Ce qui peut se faire à répétitions

nix-repl> { x = 12; } // { y = true; } // { z = { a = 12.2; }; }
{ x = 12; y = true; z = { ... }; }

Le merge peut également réécrire des champs.

nix-repl> { x = 12; y = true; } // { x = 42; }
{ x = 42; y = true; }

Supprimer un champ

Ce n’est pas forcément un outil du langage, mais c’est très pratique pour nore besoin.

Nix est fourni avec une série de fonctions, dont une qui nous intéresse builtins.removeAttrs.

Celle-ci prend deux paramètres:

le set à modifier
une liste de noms de champs à supprimer

Comme son nom l’indique permet de supprimer des champs d’un set.

nix-repl> builtins.removeAttrs { x = 12; y = true; z = 12.2; } [ "x" "z" ]
{ y = true; }

Notre fonction makeDerivation

Nous avons tous les outils, maintenant assemblage !!

Que voulons-nous faire déjà ?

Nous avons créé une dérivation normalisée:

derivation {          
  name    = "hello-world";    
  system  = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args    = [                 
    "-c"                                                                                                                               
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];

  buildPhase  = ...;
  setupPhase  = ...;
  buildInputs = ...;
}

Le but est de pouvoir remplir seulement les champs pertinents, nous donnerons le nom de makeDerivation à notre fonction.

Par exemple, notre setupPhase sera toujours identique, de même que le builder.

A contrario, d’autres champs sont à redéfinir pour chaque dérivation, comme buildPhase, buildInputs et name.

On désire également définir le <nixpkgs> que l’on désire pour conserver la reproductivité.

Et dernière contrainte, nous voulons pouvoir définir n’importe quelle variable d’environnement.

Prenons les choses dans l’ordre, réglons les problèmes un par un.

D’abord les champs obligatoires:

name
pkgs
buildPhase

Et un champ possédant une valeur par défaut buildInputs.

Ce qui nous donne la signature

makeDerivation = { pkgs, name, buildPhase, buildInputs ? [] } : {}

Ok, rajoutons le corps de la dérivation avec les champs obligatoires:

makeDerivation = { pkgs, name, buildPhase, buildInputs ? [] } : 
derivation {

  system = "x86_64-linux";

  setupPhase = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
  '';

  builder = "${pkgs.bash}/bin/bash";

  args = [                 
    "-c"                                                                                                                               
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];
}

Il manque les champs définis par la fonction, on les rajoute:

makeDerivation = { pkgs, name, buildPhase, buildInputs ? [] } : 
derivation {

  # champs hérités
  inherit name;
  inherit buildPhase;
  inherit buildInputs;

  system = "x86_64-linux";

  setupPhase = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
  '';

  builder = "${pkgs.bash}/bin/bash";

  args = [                 
    "-c"                                                                                                                               
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];
}

Sauf que l’on peut être plus malin et utiliser le merge à la place

makeDerivation = { pkgs, name, buildPhase, buildInputs ? [] } @ args : 
derivation {

  system = "x86_64-linux";

  setupPhase = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
  '';

  builder = "${pkgs.bash}/bin/bash";

  args = [                 
    "-c"                                                                                                                               
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];
} // args

Il nous manque un bout, comment rajouter les variables d’environnement personnalisées ?

Nous utilisons les paramètres optionels, plus le merge

makeDerivation = { pkgs, name, buildPhase, buildInputs ? [], ... } @ args : 
derivation ( {

  system = "x86_64-linux";

  setupPhase = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
  '';

  builder = "${pkgs.bash}/bin/bash";

  args = [                 
    "-c"
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];
} // args )

Attention!

Il faut bien entouré de paranthèses sinon le merge est appliqué sur le résultat de l’appel à la dérivation et non comme paramètre de dérivation

Ok, c’est pas mal.

Testons notre fonction:

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};

makeDerivation { 
  name = "hello-world";

  buildPhase = builtins.toFile "builder.sh" ''
    mkdir -p $out/bin
    gcc $SOURCE -o $out/bin/hello-world
  '';

  buildInputs = [ bash gcc coreutils ];

  inherit pkgs;

  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"

    void main() {
      printf("Hello World\n");
    }
  '';
}

Hum, pas fameux …

… while evaluating derivation 'hello-world'
         whose name attribute is located at «string»:7:3

       … while evaluating attribute 'pkgs' of derivation 'hello-world'

         at «string»:16:10:

           15|
           16|   inherit pkgs;
             |          ^
           17|

Après, je ne vous ai pas parlé du removeAttrs pour rien 😁

Avant de l’utiliser, qu’est ce qui se passe ?

La méthode dérivation, ne prend pas de paramètre autre que tu type “chaîne de caractères”.

Or pkgs est un set qui ne peut pas être converti en string, ce pkgs étant passé lors du merge, il se retrouve dans le paramètre de la dérivation qui le refuse.

On va donc nettoyer notre set d’entré pour qu’il n’y ait plus de champ pkgs.

makeDerivation =
{ pkgs, name, buildPhase, buildInputs ? [], ... } @args : derivation ({           
  system = "x86_64-linux";

  setupPhase = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
  '';

  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];
} // builtins.removeAttrs args ["pkgs"] )

Nous pouvons alors utiliser notre makeDerivation fraîchement réparée

deriv = with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};

makeDerivation { 
  name = "hello-world";

  buildPhase = builtins.toFile "builder.sh" ''
    mkdir -p $out/bin
    gcc $SOURCE -o $out/bin/hello-world
  '';

  buildInputs = [ bash gcc coreutils ];

  inherit pkgs;

  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"

    void main() {
      printf("Hello World\n");
    }
  '';
}

Ce qui donne

nix-repl> :b deriv

This derivation produced the following outputs:
  out -> /nix/store/ij9lwz1wm1x02zhcix5fsdzxqf969s96-hello-world
$ /nix/store/ij9lwz1wm1x02zhcix5fsdzxqf969s96-hello-world/bin/hello-world
Hello World

C’est plus court et plus lisible, non ? 😀

Essayons avec quelque chose de plus consistant.

Nous allons reprendre le projet github au commit.

On oublie pas les bonnes habitudes et on prefetch pour récupérer la signature:

$ nix-prefetch-url --unpack https://github.com/Akanoa/nix-hello/archive/9e363d35a44b00b190a5fa8376dc2d4a221d94a2.tar.gz
path is '/nix/store/dl6rj73hw5qpj14sk7wazzh16cvrjpvv-9e363d35a44b00b190a5fa8376dc2d4a221d94a2.tar.gz'
106ra1nd19y57rnzndb87d59x1vhr6magy4y46vk98d5x6fhmr6y

Il est construit via Autotools.

Et donc notre buildPhase sera:

./configure --prefix $out
make
make test
make install

Nous avons besoin de make et de gcc.

On rajoute également une busybox car make demande tout un tas de commandes. Sans busybox, cela ne fonctionnerait pas. Essayez sans pour voir. 🙂

Bon, nous avons tout, nous pouvons construire notre dérivation

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};

makeDerivation { 
  name = "hello-world";

  buildPhase = builtins.toFile "builder.sh" ''
    cd $SOURCE
    ./configure --prefix $out
    make
    make test
    make install
  '';

  buildInputs = [ busybox gcc gnumake ];

  inherit pkgs;

  SOURCE = fetchTarball {
    url = "https://github.com/Akanoa/nix-hello/archive/9e363d35a44b00b190a5fa8376dc2d4a221d94a2.tar.gz";
    sha256 = "106ra1nd19y57rnzndb87d59x1vhr6magy4y46vk98d5x6fhmr6y";
  };
  
}

Ben oui, mais non …

error: builder for '/nix/store/7lb3z8dxl1hwkmdk0irwkcxal2wbqias-hello-world.drv' failed with exit code 2;
last 10 log lines:
> ./configure: line 1460: can't create config.log: Permission denied

Le configure va vouloir créer des fichiers de même que le make. Résultat, ça ne fonctionne pas. Il faut donner accès au dossier.

Or, rappelez-vous, les sources sont dans le /nix/store qui n’appartient pas à notre utilisateur de build.

la stratégie est donc de copier les sources avant de modifier les droits du dossier pour finalement lancer la procédure à l’intérieur.

cp -r $SOURCE work
chmod -R u+w work
cd work

Ce qui nous donne au final:

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};

makeDerivation { 
  name = "hello-world";

  buildPhase = builtins.toFile "builder.sh" ''
    cp -r $SOURCE work
    chmod -R u+w work
    cd work
    ./configure --prefix $out
    make
    make test
    make install
  '';

  buildInputs = [ busybox gcc gnumake ];

  inherit pkgs;

  SOURCE = fetchTarball {
    url = "https://github.com/Akanoa/nix-hello/archive/9e363d35a44b00b190a5fa8376dc2d4a221d94a2.tar.gz";
    sha256 = "106ra1nd19y57rnzndb87d59x1vhr6magy4y46vk98d5x6fhmr6y";
  };
  
}

Et cette fois-ci notre dérivation fonctionne 😁

$ /nix/store/m9gibyx0yxn4raa4bd0xhrfa6jwxaqm8-hello-world/bin/hello 
Hello World!

On peut même se donner un dernier sucre syntaxique.

Il est possible de fusionner deux tableaux

nix-repl> [ 1 ] ++ [ 2 3 4 ]  
[ 1 2 3 4 ]

Nous pouvons utiliser cette propriété pour nous simplifier le travail en rendant la busybox “pré-remplie”.

Ne pas oublier de retirer également le champs buildInputs du merge avec args, sinon le busybox est écrasé.

makeDerivation =
{ pkgs, name, buildPhase, buildInputs ? [], ... } @args : derivation ({           
  system = "x86_64-linux";

  setupPhase = builtins.toFile "setup.sh" ''
    PATH=""
    for input in $buildInputs; do
      PATH="$PATH:$input/bin"
    done
  '';

  builder = "${pkgs.bash}/bin/bash";

  buildInputs = [ pkgs.busybox ] ++ buildInputs;
  
  args = [                 
    "-c"                                                                                                                               
    ''
    source $setupPhase
    source $buildPhase
    ''
  ];
} // builtins.removeAttrs args ["pkgs" "buildInputs" ] )

Ce qui permet de ne plus nous en soucier:

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};

makeDerivation { 
  name = "hello-world";

  buildPhase = builtins.toFile "builder.sh" ''
    cp -r $SOURCE work
    chmod -R u+w work
    cd work
    ./configure --prefix $out
    make
    make test
    make install
  '';

  buildInputs = [ gcc gnumake ];

  inherit pkgs;

  SOURCE = fetchTarball {
    url = "https://github.com/Akanoa/nix-hello/archive/9e363d35a44b00b190a5fa8376dc2d4a221d94a2.tar.gz";
    sha256 = "106ra1nd19y57rnzndb87d59x1vhr6magy4y46vk98d5x6fhmr6y";
  };
  
}

On pourrait encore rafiner plus la buildPhase pour écrire encore moins de code, mais nous allons nous arrêter là, nous avons la philosophie de création de dérivation normalisée.

Philosophie que nous appliqueront plus tard avec de meilleurs outils.

Conclusion

Nous avons bien manipulé et même trituré le langage dans tous les sens, mais vous vous doutez bien que ce n’est pas de cette façon quasi artisanale que l’on créé des dérivations dans Nix.

Dans la partie 7, nous verrons comment utiliser stdenv.mkDerivation qui n’est autre que le pendant de la fonction que nous avons créé mais en bien plus sophistiquée et directement fournie par la librairie standard!

Merci de votre lecture et à la prochaine ❤️

Partie 5 : Externaliser les sources

2023-04-21T00:00:00+00:00

Les articles de la série

Bonjour à toutes et tous! 😀

Cinquième article sur Nix.

Aujourd’hui nous allons utiliser des sources qui ne sont pas dans la dérivation, cela rendra notre dérivation plus souple.

Plus de sources !

Jusqu’à présent notre dérivation ressemble à ceci:

with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}

Nous utilisons la varaible d’environnement “$SOURCE” pour stocker un chemin de fichier local que l’on génère directement à partir de la fonction toFile.

C’est très bien si l’on a qu’un seul fichier mais si l’on commence à faire grandir le projet ça va devenir de plus en plus compliqué de suivre la cadence.

Exemple deux fichiers de sources nous donne:

with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    mkdir src
    cd src
    ln -s $SOURCE main.c
    ln -s $SOURCE2 hello.c                       
    gcc main.c -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin:${pkgs.coreutils}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
    #include "hello.c"
  
    void main() {
      printf("%s\n", hello());
    }
    '';
   SOURCE2 = builtins.toFile "hello.c" ''

    const char* hello() {
      return "Hello World";
    }
    '';
}

On introduit la dérivations pkgs.coreutils qui contient les commandes ln et mkdir.
On créé un dossier “src” et on rentre dedans
On symlink les sources dedans

Et si on veut le faire de manière cannonique, il faut en plus rajouter un header.

with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    mkdir src
    cd src
    ln -s $SOURCE main.c
    ln -s $SOURCE2 hello.c
    ln -s $HEADER  hello.h                       
    gcc main.c hello.c -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin:${pkgs.coreutils}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
    #include "hello.h"
  
    void main() {
      printf("%s\n", hello());
    }
    '';
  HEADER = builtins.toFile "hello.h" ''
      const char* hello();   
    '';
  SOURCE2 = builtins.toFile "hello.c" ''
    #include "hello.h"

    const char* hello() {
      return "Hello World";
    }
    '';
}

Si en plus, nous voulons respecter les standards, on peut même se créer le Makefile. 😇

Mais pour ce faire nous allons déporter nos sources.

Fetch

Pour tester cela, j’ai créé un projet sur github.

Nous avons appris de notre erreur, il nous faut quelque chose de stable dans le temps, de reproductible.

L’intérêt de git est de créer des signatures uniques pour chaque modification. Nous allons utiliser cette propriété pour s’assurer de la stabilité de notre dérivation.

Sur github, il est possible de voir tous les commits d’une branche.

Et ainsi récupérer le SHA1 de ce commit.

On peut alors récupérer les sources sous la forme d’une archive via une URL formatée comme suit:

https://github.com/<projet>/archive/<SHA1>.tar.gz

Mon commit est le 639841dcbc59ed24a461a9dadf6234073cdafad0.

Essayons de récupérer les sources, pour cela nous allons réutiliser la commande fetchTarball.

nix-repl> fetchTarball "https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz"
"/nix/store/83z8gfh3lmi8psikgv39fpl67awkg4fg-source"

$ ls -l /nix/store/83z8gfh3lmi8psikgv39fpl67awkg4fg-source
-r--r--r-- 1 root root   70 janv.  1  1970 hello.c
-r--r--r-- 1 root root   20 janv.  1  1970 hello.h
-r--r--r-- 1 root root 1295 janv.  1  1970 LICENSE
-r--r--r-- 1 root root   90 janv.  1  1970 main.c
-r--r--r-- 1 root root   42 janv.  1  1970 Makefile
-r--r--r-- 1 root root   83 janv.  1  1970 README.md

Magnifique, nous avons nos sources. 😃

Pour les construire, nous allons utiliser la méthode standard du Makefile.

Pour constuire les sources, il faut s’y déplacer puis lancer la commande make.

Le Makefile ressemble à ceci:

all: main.c 
	gcc main.c hello.c -o ${out}

On remarque le ${out} qui est directement défini par la dérivation. La sortie de compilation sera au bon endroit.

Nous pouvons créer la dérivation qui va bien.

nix-repl> :b with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    cd $SOURCE                   
    make        
    ''
  ];
  PATH = "${pkgs.gcc}/bin:${pkgs.coreutils}/bin:${pkgs.gnumake}/bin";
  SOURCE = fetchTarball "https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz";
}

This derivation produced the following outputs:
  out -> /nix/store/mbx1qs39fgqiyfiikfx98gbs9vvqqxnm-hello-world

$ /nix/store/mbx1qs39fgqiyfiikfx98gbs9vvqqxnm-hello-world
Hello world!

De cette manière les sources de la dérivations ne sont plus contenues par elle, mais déportées tout en conservant l’aspect de reproductibilité.

En parlant de reproductibilité, nous pouvons faire mieux. 😃

Checksum

Nix propose un outil nix-prefetch-url pour calculer la somme de contrôle ou checksum de ce que l’on télécharge.

$ nix-prefetch-url --unpack https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz
path is '/nix/store/livh28m4dpk96q347s8j17fv2k5drb8g-639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz'
0pvjw2kf0fwv569j2caqc983qk3x78znj52brr1a0av8f2c8rwjl

Attention!

L’argument --unpack est important, car sinon c’est la signature n’est pas correcte, en effet le fetchTarball procède au désarchivage du tar.gz après son téléchargement.

Sans --unpack on calcule la signature de l’archive pas de son contenu
$ nix-prefetch-url https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz
path is '/nix/store/qi5nmqi9np2jbjw4f52zakr10pa6j4pr-639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz'
1wh3vf4ydvvxyiw18wwdyr1xgcqpxnlrl0wl2wcjsysflbrxlhgp

D’ailleurs, si l’on utilise le mauvais checksum:

nix-repl> :b with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    cd $SOURCE                   
    make        
    ''
  ];
  PATH = "${pkgs.gcc}/bin:${pkgs.coreutils}/bin:${pkgs.gnumake}/bin";
  SOURCE = fetchTarball {
    url = "https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz";
    sha256 = "1wh3vf4ydvvxyiw18wwdyr1xgcqpxnlrl0wl2wcjsysflbrxlhgp";
  };
}


error: hash mismatch in file downloaded from 'https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz':
  specified: sha256:1wh3vf4ydvvxyiw18wwdyr1xgcqpxnlrl0wl2wcjsysflbrxlhgp
  got:       sha256:0pvjw2kf0fwv569j2caqc983qk3x78znj52brr1a0av8f2c8rwjl

Le système signale une incohérence entre le checksum calculé d’une part et le checksum spécifié, d’autre part.

Si le SHA1 correspond, le build est possible.

nix-repl> :b with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    cd $SOURCE                   
    make        
    ''
  ];
  PATH = "${pkgs.gcc}/bin:${pkgs.coreutils}/bin:${pkgs.gnumake}/bin";
  SOURCE = fetchTarball {
    url = "https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz";
    sha256 = "0pvjw2kf0fwv569j2caqc983qk3x78znj52brr1a0av8f2c8rwjl";
  };
}

This derivation produced the following outputs:
  out -> /nix/store/mbx1qs39fgqiyfiikfx98gbs9vvqqxnm-hello-world

Et on peut faire de de même avec le nixpkgs.

$ nix-prefetch-url --unpack https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz
1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9

On peut alors fixé également spécifier le SHA1 du nixpkgs dans la dérivation.

with import (fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz";
  sha256 = "1xk1f62n00z7q5i3pf4c8c4rlv5k4jwpgh0pqgzw1l40vhdkixk9";
}) {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''
    cd $SOURCE                   
    make        
    ''
  ];
  PATH = "${pkgs.gcc}/bin:${pkgs.coreutils}/bin:${pkgs.gnumake}/bin";
  SOURCE = fetchTarball {
    url = "https://github.com/Akanoa/nix-hello/archive/639841dcbc59ed24a461a9dadf6234073cdafad0.tar.gz";
    sha256 = "0pvjw2kf0fwv569j2caqc983qk3x78znj52brr1a0av8f2c8rwjl";
  };
}

Là on commence à avoir quelque chose qui a de la gueule! 🤩

Ainsi, même si les données pointée par l’URL changent, nous sommes capable de le détecter et d’annuler la réalisation de la dérivation.

Ce mécanisme permet de s’assurer que les sources n’ont pas été corrompues d’une manière ou d’une autre.

Conclusion

Nous commençons à nous rapprocher d’une dérivation qui est utilisable pour de vrais projets.

Dans la partie 6, nous verrons comment construire des projets plus normalisés via mkDerivation.

Merci de votre lecture ❤️

Partie 4 : Contraindre une dérivation

2023-04-20T00:00:00+00:00

Les articles de la série

Bonjour à toutes et tous! 😀

Quatrième article sur Nix.

Bilan de la situation

Dans la partie 3, nous avons réussi à compiler du C.

Cependant, nous n’avons pas tout fixé, seuls nos sources sont déterministes.

On a deux points flottants:

le /bin/sh on ne sait pas d’où il vient
la dérivation du gcc vient d’un <nixpkgs> dont on ne connait pas la version

Rendre le builder déterministe

Pour cela, nous allons déjà déterminer le /bin/sh qui est-il? que fait-il dans sa vie?

Générons une dérivation.

nix-repl> derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World 1\n");
    }
    '';
}
«derivation /nix/store/i8r1j3d07w4rnzaj7rlsyh08jz2yc04f-hello-world.drv»

Et buildons là en mode verbose à l’extérieur du repl.

$ nix-build -vvv /nix/store/zhv7hwhhhql4jk8qklidwi0kdkkj9593-hello-world.drv 2>&1 | grep "sandbox setup: bind mounting"

sandbox setup: bind mounting '/nix/store/7b943a2k4amjmam6dnwnxnj8qbba9lbq-busybox-static-x86_64-unknown-linux-musl-1.35.0/bin/busybox' to '/nix/store/zhv7hwhhhql4jk8qklidwi0kdkkj9593-hello-world.drv.chroot/bin/sh'

Là c’est un peu les entrailles de la bête.

Pour éviter tout parasites extérieurs, les builds de Nix sont réalisés dans une sandbox logicielle où tout est contrôlable.

L’une des étapes, consiste à ajouter dans cette sandbox, un exécutable /bin/sh provenant d’une version de busybox.

Mais cette version, est totalement dépendante de l’installation de Nix pour l’environnement de build et donc dépendant notamment de la version de Nix elle-même.

Pour éviter le fameux, “mais ça marche sur mon laptop”.

Nous devons vérouiller ce comportement.

Pour cela nous allons utiliser un bash provenant d’une dérivation que l’on souhaite devenir fixe.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World 1\n");
    }
    '';
}

This derivation produced the following outputs:
  out -> /nix/store/9rsg6zcismripg13mqi4yrmws5i9hq7j-hello-world

Ok, mais nous avons juste caché la poussière sous le tapis.

Le problème reste entier, on ne sait pas ce qu’est <nixpkgs>, ou plutôt son état dépend de l’état d’installation de Nix.

Ce n’est pas reproductible.

Rendre <nixpkgs> déterministe

Heureusement, il est également possible de fixer cela également.

<nixpkgs> n’est dans les faits qu’une itération parmis d’autres du projet nixpkgs.

Nix fourni des outils pour rechercher de la donnée venant d’internet, comme fetchGit ou fetchTarball.

nix-repl> builtins.fetchTarball {                                                    
  url = "https://github.com/NixOS/nixpkgs/archive/refs/tags/22.11.tar.gz";
}                                                                          
"/nix/store/nkhjmzkf9hky9h34yrfy0cgyd9pbh03v-source"

nix-repl> builtins.fetchTarball {
  url = "https://github.com/NixOS/nixpkgs/archive/refs/tags/22.05.tar.gz";
}
"/nix/store/di36mqc6y19ivaa4qjrb2l82c6dqg7m3-source"

On a bien une unicité de l’empreinte selon la version de nixpgs que l’on télécharge.

Voyons un peu ce qu’il y a dedans.

$ tree -L 1 /nix/store/nkhjmzkf9hky9h34yrfy0cgyd9pbh03v-source
/nix/store/nkhjmzkf9hky9h34yrfy0cgyd9pbh03v-source
├── CONTRIBUTING.md
├── COPYING
├── default.nix
├── doc
├── flake.nix
├── lib
├── maintainers
├── nixos
├── pkgs
└── README.md

Le dossier pkgs nous intéresse. ^^

Fonction en Nix

Si je vous donne directement la méthode pour récupérer le pkgs de notre tarball vous aller avoir une syncope, donc nous allons y aller progressivement. 😅

Cela, va nous donner un prétexte pour manipuler du Nix et un peu mieux comprendre ce que l’on fera dans les parties suivantes. ^^

D’abord la notion fonction en Nix.

Le x à gauche des deux-points : est le paramètre de la fonction. Ce qui est à droite est le corps de la fonction.

Cette fonction est stockée dans la varible inc.

Qui peut ensuite être appelée et donc évaluée avec une valeur, ici 2.

nix-repl> inc = x : x + 1                
nix-repl> inc 2                          
3

On peut mettre autant de paramètres que l’on veut, il suffit de les séparer par des :. Le dernier élément sera le corps de la fonction.

nix-repl> inc_by = x : by : x + by       
nix-repl> inc_by 4 3                     
7

En vrai, il s’agit d’une fonction qui renvoit une fonction.

nix-repl> inc_by = x : ( by : x + by )
nix-repl> inc_by 4 3                   
7

Une fonction peut également prendre un set comme paramètre d’entrée.

Ici un set à deux attributs:

Pour l’appeler, il faut donc lui passer le set correspondant.

{
  x = 7;
  y = 3;
}

nix-repl> inc_by_object = { x, by } :  x + by
nix-repl> inc_by_object { x = 7; by = 3; }    
10

Attribut par défaut

Il est également possible d’omettre un paramètre en fournissant un attribut par défaut.

Via la syntaxe

{ x ? 3 } : x

Si x est défini dans le paramètre d’entré, alors il est utilisé, sinon c’est la valeur 3 qui remplace x.

On peut alors utiliser cette propriété:

nix-repl> inc_by_object_optional = { x, by ? 1 } :  x + by
nix-repl> inc_by_object_optional { x = 7; by = 3; }    
10
nix-repl> inc_by_object_optional { x = 7; }    
8

Contexte

Nix, possède une autre particularité, il s’agit des contextes.

let default = 12;
in
{ x ? default } : x

let définit qu’une variable est déclarée et que celle-ci est disponible dans le contexte suivant le mot-clef in.

nix-repl> l = let default = 12;
  in
  { x ? default } : x

nix-repl> l { x = 3; }
3

nix-repl> l {}
12

Si l’on passe un objet contenant un attribut x, il est utilisé, si on ne passe rien c’est default qui sera évalué en tant que x.

Petit sucre syntaxique.

Il n’est pas nécessaire de stocker la fonction et son contexte dans une variable, nous pouvons l’appeler directement.

nix-repl> ( let default = 12;
  in
  { x ? default } : x ) {}
12

nix-repl> ( let default = 12;
  in
  { x ? default } : x ) { x = 3; }
3

Import

Enfin, la méthode import permet de charger les dérivations dans le contexte.

nix-repl> nixpkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.05.tar.gz") {}

nix-repl> nixpkgs.pkgs.gcc                                                                                   
«derivation /nix/store/91r1rsrc9mjh8xcppfm071lv8p46a45a-gcc-wrapper-10.3.0.drv»

Le bout du chemin

Si vous avez survécu jusque là, félicitations à vous. 😇

Il est temps de rassembler le tout.

Dans l’ordre:

on fetchTarball les sources à la version voulue
on import les dérivations
on stocke dans la variable nixpkgs les dérivations
on défini avec let et in un contexte où nixpkgs existe
dans ce contexte on créer une fonction qui prend un paramètre optionel pkgs qui a pour valeur par défaut nixpkgs.pkgs
le corps de cette fonction est notre dérivation utilisant le paramètre pkgs.
on appelle la fonction sans paramètre ce qui a pour effet de déclencher l’utilisation de la valeur par défaut du champ pkgs, donc la valeur de pkgs == nixpkgs.pkgs

En code ça donne ça:

(let 
nixpkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {} ;
in
{ pkgs ? nixpkgs.pkgs } : 
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}){}

On est d’accord, c’est pas top. Mais j’ai pas trouvé plus simple… (c’est faux) 🥲

Par contre, c’est pratique pour tester notre théorie ^^

nix-repl> :b (let 
nixpkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.05.tar.gz") {} ;
in
{ pkgs ? nixpkgs.pkgs } : 
derivation { ... }){}

This derivation produced the following outputs:
  out -> /nix/store/15xyifj30dmivl2j5frfym0081wmi7p9-hello-world

nix-repl> :b (let 
nixpkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {} ;
in
{ pkgs ? nixpkgs.pkgs } : 
derivation { ... }){}

This derivation produced the following outputs:
  out -> /nix/store/dab6w96pj7vgrw3n64kk4c8d819w08lc-hello-world

Pour deux <nixpkgs> différents, nous avons bien deux empreintes différentes et reproductibles ! 🎉

On peut cocher tout le monde ^^

Simplifier notre dérivation

Alors en fait, on peut dratisquement simlplifier tout ça, mais je ne l’ai trouvé qu’après coup… ^^’

La première avancée, est qu’on peut se débarasser de la fonction et de l’attribut optionnel.

Opérateur with

En utilisant le mot clef with, qui a pour rôle de démonter une structure et de mettre chacun de ses attributs dans le contexte courant.

Donc pkgs de nixpkgs.pkgs devient disponible après le with pour le corps de la dérivation.

let
nixpkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
in
with nixpkgs;
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}

Se débarasser du contexte

Et comme nous n’avons pas non plus besoin d’isolation de contexte, on peut également faire sauter le let et le in

with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/release-21.11.tar.gz") {};
derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "${pkgs.bash}/bin/bash";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}

Et là tout de suite, ça respire! 😄

J’ai laissé dans l’article le chemin de croix, parce que ça fait manipuler le langage et c’est pas pire, même si le résultat était désastreux. 🤣

Remarque
PATH = "${pkgs.gcc}/bin";
Peut se remplacer en
PATH = "${gcc}/bin";
Car, <nixpkgs> expose directement pkgs, l’import est donc capable d’aller chercher les dérivations du dossier pkgs et de les exposer.

Conclusion

Nous avons enfin une dérivation reproductible capable de compiler du C.

Dans la partie 5, nous verrons comment déporter les sources de la dérivations.

Merci de votre lecture ❤️

Partie 3 : Première utilisation de Nixpkgs

2023-04-19T00:00:00+00:00

Les articles de la série

Bonjour à toutes et tous! 😀

Troisième article sur Nix.

Nixpkgs

Dans la partie 2, nous avons réalisé une dérivation, mais elle ne fait quasiment rien, et surtout pas ce que l’on veut.

C’est à dire compiler du C.

On a besoin de plus! On a besoin d’un compilateur! On a besoin de gcc.

Et donc de sa dérivation ou au moins de son paquet.

Pour cela nous allons appeler repl différemment.

Nous rajoutons un argument --file '<nixpkgs>.

$ nix repl --file '<nixpkgs>'
Welcome to Nix 2.15.0. Type :? for help.

Loading installable ''...
Added 18779 variables.

Ah! Il y a du changement, il nous dit qu’il a chargé plein de variables.

Le ‘<nixpkgs>’ est un alias pour dire d’aller chercher toutes les dérivations de nixpkgs, le repo officiel de Nix.

Donc maintenant dans votre repl, vous avez accès à toutes les dérivations qui ont pu être faites par la communautée.

Exemple, gcc.

Lorsque l’on a fait un

$ nix-shell -p gcc

On a dans les faits déclaré un environnement où le paquet “gcc” était disponible.

Dans le repl, on peut faire de même, la variable qui nous intéresse est pkgs, elle contient toutes les dérivations. Dont celle de gcc.

nix-repl> pkgs.gcc
«derivation /nix/store/wfb8f6nsrnfhpw7ya1dwj3k9d4vx6li1-gcc-wrapper-12.2.0.drv»

On peut d’ailleurs aller voir à quoi elle ressemble.

$ nix derivation show /nix/store/wfb8f6nsrnfhpw7ya1dwj3k9d4vx6li1-gcc-wrapper-12.2.0.drv

{
  "/nix/store/wfb8f6nsrnfhpw7ya1dwj3k9d4vx6li1-gcc-wrapper-12.2.0.drv": {
    "args": [
      "-e",
      "/nix/store/6xg259477c90a229xwmb53pdfkn6ig3g-default-builder.sh"
    ],
    "name": "gcc-wrapper-12.2.0",
    "builder": "/nix/store/dsn6vl7x1hbn1akgpxync19gpx2dzy8w-bootstrap-tools/bin/bash",
    "env": {
      "out" : "/nix/store/nlgyw2fv0cm8rkz8qm1jyw78vyif1bl9-gcc-wrapper-12.2.0",
      ...
    }
    "system": "x86_64-linux",
    ...
  }
}

( J’ai tronqué plein de champ, sinon c’était trop long )

Mais comme vous pouvez le voir, ça reste une dérivation “classique”.

Builder avec gcc

Testons d’appeler gcc dans notre builder.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc --version > $out         
    ''
  ];
}
error: builder for '/nix/store/bfrw7x8b09r53fkhmif89jslcv0zr0fp-hello-world.drv' failed with exit code 127;
       last 1 log lines:
       > sh: gcc: not found
       For full logs, run 'nix-store -l /nix/store/bfrw7x8b09r53fkhmif89jslcv0zr0fp-hello-world.drv'.

Arf! 😩

Bon petite expérience, où est gcc sur le disque?

$ nix-shell -p gcc
[nix-shell:/dir]$ which gcc
/nix/store/nlgyw2fv0cm8rkz8qm1jyw78vyif1bl9-gcc-wrapper-12.2.0/bin/gcc

Ok, donc c’est du “$out/bin/gcc”. Très bien.

Retour au repl.

nix-repl > "${pkgs.gcc}"
[nix-shell:~/Documents/Workshop/nix/hello]$ which gcc
/nix/store/nlgyw2fv0cm8rkz8qm1jyw78vyif1bl9-gcc-wrapper-12.2.0

Ok, donc interpoler une dérivation donne le chemin de sortie de cette dérivation

nix-repl > "${pkgs.gcc}/bin/gcc"
[nix-shell:~/Documents/Workshop/nix/hello]$ which gcc
/nix/store/nlgyw2fv0cm8rkz8qm1jyw78vyif1bl9-gcc-wrapper-12.2.0/bin/gcc

On peut également concaténer des chaîne de caratères. Maintenant le chemin est complet.

Plus qu’à l’introduire dans le builder et l’affaire est dans le sac.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    ${pkgs.gcc}/bin/gcc --version > $out         
    ''
  ];
}

This derivation produced the following outputs:
  out -> /nix/store/kzwd92if64f115pvg46n7sdc1x2wp6ir-hello-world

nix-repl> :e /nix/store/kzwd92if64f115pvg46n7sdc1x2wp6ir-hello-world
gcc (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Et boom ! on a gcc ! 💥

Modifier le PATH

Oui mais c’est pas top, les scripts de build standards n’auront jamais ${pkgs.gcc}/bin/gcc seulement gcc.

Pour résoudre le problème, on doit ramener gcc dans le PATH du builder

On va introduire une nouvelle règle de la fonction derivation.

Qui dit que l’on peut générer des variables d’environnements comme bon nous semble.

Exemple:

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";
  value = "tata";     
  args = [                 
    "-c"                                                                                                                               
    ''                       
    echo $value > $out         
    ''
  ];
}

This derivation produced the following outputs:
  out -> /nix/store/l0zl8hhcpywsvzzgmyxzxjf61hyqwq4i-hello-world

nix-repl > :e /nix/store/l0zl8hhcpywsvzzgmyxzxjf61hyqwq4i-hello-world
tata

Nous ce que l’on veut définir c’est “$PATH”.

Voyons son contenu.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    echo $PATH > $out         
    ''
  ];
}

This derivation produced the following outputs:
  out -> /nix/store/lvjhj4zgqrvcq2sviwhxii5mw3hdali5-hello-world

nix-repl> :e /nix/store/lvjhj4zgqrvcq2sviwhxii5mw3hdali5-hello-world
/path-not-set

Bon, clairement nada ^^

On peut donc s’amuser.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc --version > $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
}

This derivation produced the following outputs:
  out -> /nix/store/48vlxdr5bhhcgsz7z4plhaxdsbz35i3m-hello-world

nix-repl> :e /nix/store/48vlxdr5bhhcgsz7z4plhaxdsbz35i3m-hello-world

gcc (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Et re-boom ! on a gcc et pas en format bizare ! 💥💥

Définir des fichiers

Maintenant que nous avons un compilateur, il nous faut des sources.

Nix propose dans sa librairie standard une fonction appelée toFile.

On va faire comme dans l’exemple mais au lieu de déclarer un builder que nous avons déjà, nous allons déclarer le main.c.

nix-repl> builtins.toFile "main.c" ''
  #include "stdio.h"

  void main() {
    printf("Hello World");
  }
  ''
"/nix/store/9vmwahqfcx6909widh6g9xr736in950q-main.c"

$ file /nix/store/9vmwahqfcx6909widh6g9xr736in950q-main.c
/nix/store/9vmwahqfcx6909widh6g9xr736in950q-main.c: C source, ASCII text

$ cat /nix/store/9vmwahqfcx6909widh6g9xr736in950q-main.c
#include "stdio.h"

void main() {
  printf("Hello World");
}

Ok, donc c’est aussi un chemin et dedans nous avons le main.c.

On peut alors définir une variable d’environnement $SOURCE qui contiendra ce chemin.

Puis modifier la commande gcc dans le builder pour compiler.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World");
    }
    '';
}

This derivation produced the following outputs:
  out -> /nix/store/m6pd92z8rm9a2ia3qxml096cc33z1g2l-hello-world

Bon, ça marche ^^

Voyons le résultat…

$ file /nix/store/m6pd92z8rm9a2ia3qxml096cc33z1g2l-hello-world
/nix/store/m6pd92z8rm9a2ia3qxml096cc33z1g2l-hello-world: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/1n2l5law9g3b77hcfyp50vrhhssbrj5g-glibc-2.37-8/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, not stripped

Ok, ça sent bon, c’est une executable.

Ben éxécutons-le!

$ /nix/store/m6pd92z8rm9a2ia3qxml096cc33z1g2l-hello-world
Hello World$

Cool! 😎

Bon, par contre le “$” attaché c’est pas trop.

Faisons une autre version.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";   
  args = [                 
    "-c"                                                                                                                               
    ''                       
    gcc $SOURCE -o $out         
    ''
  ];
  PATH = "${pkgs.gcc}/bin";
  SOURCE = builtins.toFile "main.c" ''
    #include "stdio.h"
  
    void main() {
      printf("Hello World\n");
    }
    '';
}

This derivation produced the following outputs:
  out -> /nix/store/807y2c1zj9zz8p8b5ki0a99fkm0lw0w7-hello-world

$ /nix/store/807y2c1zj9zz8p8b5ki0a99fkm0lw0w7-hello-world
Hello World 
$

Ah, beaucoup mieux. 😃

Comme vous pouvez l’observez, une minuscule modification dans le main.c, a eu des répercussions dramatiques sur l’empreinte de la dérivation.

v1 : m6pd92z8rm9a2ia3qxml096cc33z1g2l-hello-world
v2 : 807y2c1zj9zz8p8b5ki0a99fkm0lw0w7-hello-world

C’est cela qui permet d’être certain de savoir ce que l’on manipule.

Conclusion

Dans cette partie, nous avons appris à créer une dérivation capable de compiler du C.

Cependant, nous n’avons pas tout fixé, seul nos sources sont déterministes.

Dans la partie 4 nous verrons comment rendre déterministe notre dérivation.

Merci de votre lecture ❤️

Partie 2 : Première dérivation

2023-04-18T00:00:00+00:00

Les articles de la série

Bonjour à toutes et tous! 😀

Deuxième article sur Nix.

Cette fois-ci, on fait vraiment du Nix.

Mais d’une façon un peu différente de ce que j’ai pu trouver sur internet.

Ok, les dessins vus en partie 1 c’est rigolo, mais en vrai, comment je peux créer ces paquets ?

C’est là que les choses sérieuses débutent! 🥲

Le paquet que l’on veut créer

Nous allons faire le paquet le plus simple du monde.

Un hello-world en C.

Pour cela, il nous faut des sources.

#include "stdio.h"

void main() {
  printf("Hello World");
}

Normalement pour compiler on fait un coup de

gcc main.c -o result

Et bien allons-y ! Mais utilisons ce qu’on sait déjà faire.

nix-shell -p gcc

On obtient alors un shell avec gcc

[nix-shell:~/path]$ gcc --version
gcc (GCC) 12.2.0

Compilons et rendons exécutable le fichier

[nix-shell:~/path]$ gcc main.c -o result
[nix-shell:~/path]$ chmod +x result
[nix-shell:~/path]$ ./result
Hello World
[nix-shell:~/path]$ exit

Wouhou, on sait encore faire du C 😎

Découverte de nix-repl

Bon assez rigolé, attaquons les choses sérieuses.

Mais nous allons le faire très progressivement.

Tout d’abord et en dehors d’un nix-shell, nous allons utiliser le REPL “Real Event Print Loop” de Nix. Il s’agit d’un programme qui permet de manipuler Nix en mode interactif.

$ nix repl
Welcome to Nix 2.15.0. Type :? for help.

Si tout se passe bien, vous devriez avoir un affichage semblable.

Il permet de taper des expressions qui seront analysées et exécutées.

nix-repl > 1 + 2
3

La fonction derivation

Créons maintenant, une dérivation dont on a si souvent parlé dans la partie précédente.

nix-repl > derivation
«lambda @ //builtin/derivation.nix:5:1»

Ok, “lambda” … Cela signifie qu’il s’agit d’une fonction.

En Nix, pour appeler une fonction on fait

expr {}

Pour les pros, oui je sais c’est un raccourci, j’explicite dans la partie 3 ^^

Allons-y pour la derivation.

nix-repl > derivation {}
error: attribute 'name' missing

Donc la fonction prend un attribut qui est name;

Les attributs sont les champs de structures de données comme ci-dessous:

{ x = 1; y = 2; }

En Nix on nomme ceci un set.

Remarquez le point virgule ; à la fin de chaque attribut

Nous allons donc donner à notre fonction un set comportant l’attribut name et qui a pour valeur “hello-world”.

nix-repl > derivation { name = "hello-world"; }
error: required attribute 'builder' missing

Bon ça progresse ! Je vais pas vous faire tous les attributs manquants, un à un ^^

Voici un set complet

nix-repl > derivation { name = "hello-world"; builder = "fake-builder"; system = "fake-system";}
«derivation /nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv»

Wouhou ! Vous venez de créer votre première dérivation !

Derivation Nix

Le retour de vous avez créé a tout l’air d’être un chemin sur l’ordi.

Sortons du REPL avec ctrl+d.

Voyons ce qu’il en est.

$ file /nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv
/nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv: ASCII text, with no line terminators

C’est bien un fichier, visualisons son contenu.

$ cat /nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv

Derive([("out","/nix/store/vzv4g8bavybrp4682xidd5dn7r9w8lf6-hello-world","","")],[],[],"fake-system","fake-builder",[],[("builder","fake-builder"),("name","hello-world"),("out","/nix/store/vzv4g8bavybrp4682xidd5dn7r9w8lf6-hello-world"),("system","fake-system")])

Nix propose une alternative plus sympatique pour le visualiser.

$ nix derivation show /nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv

error: experimental Nix feature 'nix-command' is disabled; use '--extra-experimental-features nix-command' to override

Bon, il faut rajouter l’argument.

$ nix derivation show /nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv --extra-experimental-features nix-command

{
  "/nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv": {
    "args": [],
    "builder": "fake-builder",
    "env": {
      "builder": "fake-builder",
      "name": "hello-world",
      "out": "/nix/store/vzv4g8bavybrp4682xidd5dn7r9w8lf6-hello-world",
      "system": "fake-system"
    },
    "inputDrvs": {},
    "inputSrcs": [],
    "name": "hello-world",
    "outputs": {
      "out": {
        "path": "/nix/store/vzv4g8bavybrp4682xidd5dn7r9w8lf6-hello-world"
      }
    },
    "system": "fake-system"
  }
}

Vu que c’est experimental mais pas complet cassé, nous allons désactiver les warnings.
$ vim ~/.config/nix/nix.conf
experimental-features = nix-command

Dans ce qui ressemble a du JSON, nous avons une clef avec le nom de notre dérivation <deriv> et dedans une clef <deriv>.env.out.

Celle-ci a pour valeur un autre chemin /nix/store/vzv4g8bavybrp4682xidd5dn7r9w8lf6-hello-world.

Si on tente de l’atteindre.

$ ls /nix/store/vzv4g8bavybrp4682xidd5dn7r9w8lf6-hello-world
ls: cannot access '/nix/store/vzv4g8bavybrp4682xidd5dn7r9w8lf6-hello-world': No such file or directory

Normal, nous avons déclaré notre dérivation mais nous ne l’avons pas encore réalisée.

C’est donc logique et plutôt rassurant que le paquet hello-world n’existe pas encore.

Réalisation de la dérivation

Réalisons notre dérivation !

Pour cela, nouvelle commande : nix-build.

$ nix-build /nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv

this derivation will be built:
  /nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv
error: a 'fake-system' with features {} is required to build '/nix/store/z4lc26wzbma1c5s7spp98zz7xz99m5gh-hello-world.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test, uid-range}

Ok, notre dérivation est pas top, je crois que nous allons devoir repartir sur la table à dessins. 😢

On est de retour dans le REPL.

Changeons l’attribut system pour ce qu’il demande.

nix-repl> derivation { name = "hello-world"; builder = "fake-builder"; system = "x86_64-linux";}
«derivation /nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv»

Le chemin est complètement différent, pour cette seconde dérivation.

$ nix derivation show /nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv
{
  "/nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv": {
    "builder": "fake-builder",
    "env": {
      "system": "x86-64_linux"
    }
  }
}

Et notre système est à la bonne valeur.

On relance un build et on croise les doigts. 🤞

$ nix-build /nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv
this derivation will be built:
  /nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv
building '/nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv'...
error: executing 'fake-builder': No such file or directory
error: builder for '/nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv' failed with exit code 1;
       last 1 log lines:
       > error: executing 'fake-builder': No such file or directory
       For full logs, run 'nix-store -l /nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv'.

Ah! De l’avancement. des erreurs mais on progresse.

Je trouve le chemin de modification un peu longuet: repl, derivation, exit repl, build.

Est-ce que l’on pourrait rester dans le REPL pour build ? Oui, sinon je poserai pas la question. 😝

Il suffit de rajouter :b devant la déclaration de la dérivation.

nix-repl> :b derivation { name = "hello-world"; builder = "fake-builder"; system = "x86_64-linux";}
error: builder for '/nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv' failed with exit code 1;
       last 1 log lines:
       > error: executing 'fake-builder': No such file or directory
       For full logs, run 'nix-store -l /nix/store/85pf9z8ps92lf115wpfy5k493l096g99-hello-world.drv'.

Bon il trouve pas le builder, et pour cause, il n’existe pas.

Le builder

Un builder est un exécutable qui a pour but de réaliser la dérivation et de mettre le contenu dans <deriv>.env.out celui du retour de la commande nix derivation show..

Pour cela nous allons rajouter un quatrième paramètre args qui va nous permettre de définir les arguments passés au builder.

Ici ça sera l’équivalent d’écrire:

/bin/sh -c "echo toto > $out"

-c pour lire le stdin et l’exécuter.

Et nous allons utiliser un builder qui existe, celui-ci sera /bin/sh.

J’explique dans la partie 3 pourquoi. ^^

Le env de <deriv>.env.out est ici pour signaler qu’une variable d’environnement “$out” est définie à la valeur du chemin de sortie de la dérivation.

Donc ici, notre builder se contente de venir écrire toto à ce chemin. Qui devient un fichier.

nix-repl> :b derivation {          
  name = "hello-world";    
  system = "x86_64-linux";
  builder = "/bin/sh";     
  args = [                 
    "-c"                                                                                                                               
    ''                       
    echo toto > $out         
    ''
  ];
}

This derivation produced the following outputs:
  out -> /nix/store/alrzzi9kljsqazv5a34hspx531wjknz7-hello-world

On peut s’en convaincre avec:

$ file /nix/store/alrzzi9kljsqazv5a34hspx531wjknz7-hello-world
/nix/store/alrzzi9kljsqazv5a34hspx531wjknz7-hello-world: ASCII text

$ cat /nix/store/alrzzi9kljsqazv5a34hspx531wjknz7-hello-world
toto

Félicitation ! Vous venez de réaliser votre première dérivation!! 🎉 🍾

Conclusion

Nous avons bien une dérivation, elle est fonctionnelle, ne compile pas encore de C.

On verra dans la partie 3 comment compiler.

Merci de votre lecture ❤️

Partie 1 : Premier pas avec Nix

2023-04-14T00:00:00+00:00

Les articles de la série

Bonjour à toutes et tous! 😀

Premier article sur le gestionnaire de packages Nix et son langage.

Cela peut aussi être un système d’exploitation complet, mais chaque chose en son temps. 😅

Je ferai mon installation sur linux mais la documentation officielle vous permet de l’installer n’importe où même sur du windows.

Dans cette partie, je vous explique comment l’installer et quelle est la philosophie adoptée par Nix pour gérer les paquets.

La pratique viendra dans la partie 2.

Installation

Nix est installable via un scrip bash

curl -L https://nixos.org/nix/install | sh -s -- --daemon

Celui-ci va vous poser un certain nombre de questions qui vont vous permettre de définir le comportement d’installation.

Moi, j’ai choisi le multi-user et donc le besoin d’être sudo.

Pour vérifier que tout marche, rendez-vous dans un autre shell.

$ nix --version
nix (Nix) 2.15.0

Les environnements éphémères

Faisons un peu de magie noire.

Des fois nous avons besoin d’un logiciel à une certaine version pour faire des choses.

Mais c’est compliqué, il faut installer tout un tas de dépendances, ça “pourrit” le disque et on oublie de désinstaller après coup, ou on ne sait plus où on l’a installé.

Nix permet de créer des environnements éphémères pour tester des choses. Environnements qui peuvent facilement se nettoyer.

Exemple, je suis sur un système qui ne possède pas python.

$ python
Command 'python' not found

Fâcheux, 2 solutions, je fais un apt install de python même si j’en ai besoin que maintenant.

Ou … J’utilise Nix, yes je vois que ça suit derrière 😛

Pour cela, on créé ce que l’on appelle un nix-shell.

Mais pas n’importe lequel, on lui donne des arguments, par exemple le python que l’on désire.

Pour cela, on va sur https://search.nixos.org !

On recherche le paquet que l’on désire, par exemple python 3.11.

Et cela nous donne le nom du paquet, ici python311.

Plus qu’à injecter ça dans nix-shell

$ nix-shell -p python311

Selon votre shell, vous devriez avoir une indication de changement de contexte.

[nix-shell:~/dir]$

Maintenant, si on retente le

[nix-shell:~/dir]$ python --version
Python 3.11.2

Si on exit

$ exit
$ python
Command 'python' not found

Le python n’est toujours pas installé à l’extérieur 😀

Et maintenant si l’on veut, 2 versions de python.

python 3.11
python 2.7

$ nix-shell -p python311 python27

Il va vous engueuler !

Known issues:
        - Python 2.7 has reached its end of life after 2020-01-01. See https://www.python.org/doc/sunset-python-2/.

       You can install it anyway by allowing this package, using the
       following methods:

       a) To temporarily allow all insecure packages, you can use an environment
          variable for a single invocation of the nix tools:

            $ export NIXPKGS_ALLOW_INSECURE=1

Bien Madame, tout de suite Madame.

$ NIXPKGS_ALLOW_INSECURE=1 nix-shell -p python311 python27

Après un certain temps, vu que l’on est en train de compiler les sources de python, vous entrerez dans un shell.

[nix-shell:~/dir]$ python --version
Python 3.11.2

[nix-shell:~/dir]$ python2 --version
Python 2.7.18.6

Plutôt cool non ? 😎

Et bien-sûr on peut le faire avec n’importe quoi, pourvu qu’une bonne âme l’ait déjà packagé.

nix-shell -p rustc cargo

Créons un projet rust.

[nix-shell:~/dir]$ rustc --version
rustc 1.68.2 (9eb3afe9e 2023-03-27) (built from a source tarball)

[nix-shell:~/dir]$ cargo init toto
Created binary (application) package

[nix-shell:~/dir]$ cd toto

[nix-shell:~/dir]$ cargo run
   Compiling toto v0.1.0 (/home/noa/Documents/Workshop/nix/toto)
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/toto`
Hello, world!

Voilà! 30 secondes pour commencer à bosser.

Vous sortez et pouf, tout disparaît ^^

Je sais pas si vous avez remarqué mais, le premier environnement est long à installer mais les suivants c’est instantané.

Il y a sûrement du cache quelque part. 🤔

La réponse est oui ! 🙂

Pour s’en convaincre il suffit de faire un which.

[nix-shell:~/dir]$ which rustc
/nix/store/hd6l85dw0i9zy7j0h52w9s8smyymha3r-rustc-1.68.2/bin/rustc

$ exit
$ which rustc
/home/noa/.cargo/bin/rustc

A l’intérieur et au-dehors de l’environnement, ce ne sont pas les mêmes binaires.

Tout ce qui est utilisable dans l’environnement éphémère est stocké dans un des sous répertoires du dossier /nix/store.

La philosophie derrière Nix

Si vous n’êtes pas familier de la programmation fonctionnelle, nous allons devoir faire un peu de théorie.

Le pire cauchemar d’un fonctionnaliste c’est d’avoir des effets de bord dans son système.

Et qu’est ce qu’un effet de bord ?

Et bien c’est un paramètre non fixé qui fait varier de manière incontrôlée le système.

Imaginez que vous avez une fonction qui doit renvoyer la date d’aujourd’hui.

fun return_now() -> int
  return now()

display return_now();

Cette fonction est impure, car en fonction du moment où vous allez l’appeler, la valeur va varier.

Pour que celle-ci soit pure, il faut que le temps soit déterministe. Et donc que now() le soit.

fun return_now_pure(clock : time) -> int
  return clock.now()

clock = time().set_now("14/04/2023 00:00");

display return_now(clock);

Cette fois-ci, nous sommes capable de décider de ce que now() retourne. La fonction return_now_pure est donc pure.

Maintenant, que pourrait signifier la pureté dans un contexte de paquets à installer ?

Déjà c’est quoi un paquet ?

Très grossièrement, un paquet c’est:

un certain nombre de binaires
un certain nombre de fichiers de configuration
un certain nombre de paquets en dépendances:
- un certain nombre de binaires
- un certain nombre de fichiers de configuration
- un certain nombre de paquets en dépendances:
  - …

Bon clairement on a une récursion de concepts ^^

Et donc rendre pur un paquet c’est rendre pure cette récursion.

Cela manque de dessins!

Imaginons le paquet A.

Celui-ci est constitué de sources, qui doivent être compilées.

Cela produit un binaire.

Nous voulons être convaincus du contenu de ce que l’on manipule.

Pour cela nous allons utiliser une fonction de hachage crytographique.

Une fonction de hachage ou hash a pour particularité de renvoyer la même valeur de retour pour un contenu en entrée donnée.

Nous allons utiliser cette fonction pour venir créer l’empreinte des sources que l’on souhaite compiler.

Si le contenu des sources évolue, son empreinte en fait d’autant.

Notre paquet A, possède également un fichier qui est nécessaire à son fonctionnement.

On étiquette alors le paquet avec l’empreinte calculée précédemment.

Le souci c’est que si le contenu du fichier accompagnant le binaire évolue, mais que le binaire reste identique.

Alors, l’étiquette restera la même ! Or ça c’est impur. De l’extérieur, nous pensons savoir ce que l’on manipule alors que finalement cette modification peut avoir des répercussions sur le fonctionnement du paquet A.

Pour éviter cela, nous allons également ajouter le contenu du fichier dans le calcul d’empreinte.

Ainsi, peu importe les modifications, l’empreinte évoluera. L’utilisateur du paquet A n’est pas “pris en traître”

On créé alors une série de “paquets A”, mais étiquetés différemment, ce qui reflète l’état interne du contenu du paquet.

Si on en revient à la première chose dont on a parlé, on a dit que le binaire devait être compilé, mais compilé par quoi ?

Et bien par un compilateur.

Compilateur lui même possède une version.

Et du coup, si la version du compilateur vient à changer, qu’est ce qui garantit que le binaire résultant ne soit pas altéré ?

Et bien, rien !

Or, nous voulons un système déterministe.

Ce que nous allons faire, c’est également ajouter dans le calcul de l’empreinte, le compilateur lui-même.

Ainsi, compiler les même sources, mais avec un compilateur différent, nous donne une empreinte finale différente.

Étant donné que l’on commence à planifier les choses. Nous allons réaliser un plan de construction.

Ce plan de construction se nomme dans le monde de Nix, une dérivation.

Cette dérivation nous explique que pour compiler le paquet A, nous avons besoin:

du compilateur à la version v1.0
des sources à la version v1.0.1
du fichier à la révision rev 2

Si tous les ingrédients sont réunis, et dans cet état précis, la dérivation créera un paquet A étiqueté #e12d.

En imaginant que le compilateur v1.0 est dans le paquet compilateur étiqueté #7a84.

Alors, tout comme nous utilisons une dérivation pour obtenir, le paquet A, nous allons utiliser la dérivation à l’étiquette #7a84 pour obtenir le paquet compilateur étiqueté #7a84.

On dit que l’on réalise la dérivation.

On peut alors mettre à jour notre dérivation du paquet A, qui désormais référence également le dérivation du compilateur #7a84.

Pour obtenir notre compilateur, nous avons alors 3 choix:

réaliser la dérivation pour obtenir le paquet, récupérer le compilateur
télécharger le paquet déjà réalisé
utiliser le cache local de la dérivation déjà réalisée

On reparlera du cache plus tard dans la série.

Imaginons, maintenant une dérivation paquet B qui demande, une dérivation de paquet A, de paquet C et des sources.

Étant donné que toutes les entrées sont fixées, la dérivation garantie que pour une collection d’entrée donnée, le contenu du paquet B sera TOUJOURS identique.

Nous avons un système de création de paquet qui est pur !

D’une manière générale, pour une collection de dérivation d’entrées et de données définie. Nous sommes toujours capable de créer une dérivation qui donnera un paquet donc le contenu est déterministe et donc peut être connu à la simple lecture de son empreinte. 😄

Conclusion

Dans cette partie, nous avons un peu joué avec la partie utilisateur du package manager et expliqué comment Nix s’assurait de la pureté, je veux plutôt dire de la reproductibilité des builds.

On verra dans la partie 2 comment créer nos propres packages.

Merci de votre lecture ❤️