Nix

Découverte de Nix et de Flake

Explication du langage Nix et de Flake, mais aussi comment les utiliser pour créer ses propres environnements de travail.

Introduction

Avant de commencer, je tiens à dire que j’ai fait ce post en partie pour l’entreprise Unova où je travaillais. Je tiens à les remercier pour m’avoir autorisé à réutiliser le contenu sur mon site.

Nix est un gestionnaire de paquets basé sur le langage Nix. Il permet de gérer facilement une configuration système, d’un projet ou même d’un package (logiciel) et surtout de s’assurer de la reproductibilité de la configuration. Cependant, par défaut, Nix ne permet pas de “lock” la version de la configuration sur l’ensemble des machines. C’est pour cela que les développeurs développent Flake.

Flake est une feature experimentale qui permet de lock les dépendances sur une version très précise. Un peu comme le Gemfile.lock ou même le package-lock.json.

Grâce au coté déclaratif de Nix, on peut par exemple facilement tester un outils sans devoir l’installer de manière permanente sur sa machine avec :

1
2
3
4
5
6
7

nix run nixpkgs#cowsay Salut # Lance directement la commande cowsay avec l'argument Salut

nix shell nixpkgs#cowsay # Prépare un shell avec la commande cowsay dedans
cowsay Salut # La commande est disponible
exit # On revient sur notre shell de base

nix-collect-garbage # On nettoie les dépendances inutiles (Supprime cowsay)

Ou même configurer son shell existant pour pouvoir développer sur un logiciel

1

nix develop nixpkgs#cowsay # Prépare le shell actuel avec toutes les dépendances nécessaires pour compiler et exécuter cowsay

Attention: Il créer un shell avec les outils nécessaires pour travailler dessus, mais ne récupère pas le projet en lui-même.

Le langage Nix

Nix est un langage de programmation dédié pour la configuration d’une machine ou compilation de programme donc il peut être compliqué à prendre en main. Il est différent des langages traditionnels, on peut le voir comme un language de construction d’un attribut set qui sera utilisé ensuite.

Un attribut set peut-être vu comme un objet JS.

1

{ a = 12; b = 14; }

Je ferrais surement un post pour expliquer plus en détail le langage car il est assez complexe. J’ai rajouté quelques liens utiles ici

Structure d’un Flake

Partie inputs

1
2
3
4

inputs = {
  nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
  flake-utils.url = "github:numtide/flake-utils";
};

Dans cette exemple, on peut voir que j’ai rajouté les dépendances nixpkgs et flake-utils.

La dépendance nixpkgs correspond au repo github nixpkgs. En général, on l’utilise pour récupérer des packages ou utiliser les outils mis à disposition par les contributeurs de NixOS.

On peut retrouver dans le repo.

  • /nixos Contiens la configuration pour nixos (La distribution basée sur Nix)
  • /pkgs Contiens tous les packages (ex: ruby_3_3)

Les nouveaux packages doivent être mis dans le sous-dossier by-name. C’est un nouveau standard du projet. Les packages déjà existants migrent dessus petit à petit. Si un package manque, n’hésitez surtout pas à contribuer au projet.

  • lib Contiens plein d’outils pratiques comme makeLibraryPath ou makeIncludePath
  • doc Contiens la doc ^^
  • maintainers Contiens la liste de tous les mainteneurs des packages.

La dépendance flake-utils contient des helpers pour faciliter la configuration pour un ensemble de systèmes (x86_64-linux, x86_64-darwin, …).

darwin Correspond au système Mac OS

Partie outputs

Outputs est une fonction qui prend en paramètre un attribute set avec pour attributs self et les dépendances déclarées dans la partie inputs.

Dans le cas ou l’on a les dépendances suivantes:

1
2
3
4
5

inputs = {
  nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
  flake-utils.url = "github:numtide/flake-utils";
  mon-input-custom.url = "github:mongithub/monprojet";
};

On aura les entrées suivantes dans outputs:

1
2
3
4
5
6
7
8

outputs = { self, nixpkgs, flake-utils, mon-input-custom }:
#                 ^^^^^^^  ^^^^^^^^^^^  ^^^^^^^^^^^^^^^^
#                 Doit avoir le même nom que dans les inputs
{
  devShells.x86_64-linux.default = {...};
  packages.x86_64-linux.default = {...};
  nixosConfigurations.x86_64-linux.default = {...};
}

Les attributs que l’on peut retrouver dans outputs sont:

  • devShells Des environnements de développement.
  • nixosConfigurations Des configurations de NixOS (La distribution Linux)
  • darwinConfigurations Des configurations pour Mac OS En savoir plus
  • packages Des packages (Docker, ruby, go, rust, …)
  • [...]

Exemple de flake

Dans cette example, j’ai déclaré un environnement de travail utilisable avec la commande nix develop. J’ai rajouté en dépendances la librairie openssl, la commande redis et un script au lancement du shell.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  description = "Ma description";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };
      in
      {
        devShells = rec {
          default = pkgs.mkShell {
            inputsFrom = with pkgs; [openssl];
            packages = with pkgs; [redis];
            shellHook = ''
              echo "Votre shell est configuré"
            '';
          };
        };
      });
}

Mettre à jour le flake.lock

Le flake.nix vient avec un fichier flake.lock qui permet de vérrouiller la version de chaque input. Si on souhaite mettre à jour nos packages pour notre projet. Il est nécessaire de le mettre à jour.

On retrouve deux commandes:

  • nix flake update Mets à jour tous les inputs
  • nix flake lock --update-input <input> Mets à jour uniquement un input en particulier

Débugger sa configuration avec la console nix

Il existe une console depuis la version expérimentale de nix nix-command. On peut y accéder avec la commande nix repl.

Normalement, on doit avoir un shell comme ci-dessous

1
2
3

$ nix repl
Welcome to Nix 2.18.2. Type :? for help.
nix-repl>

Dedans, on peut écrire n’importe quoi en nix mais aussi lui demander de charger notre configuration flake avec l’aide de la commande :lf [path racine ou ce trouve le flake]

lf est l’abréviation de Load Flake

1
2
3
4

$ nix repl
Welcome to Nix 2.18.2. Type :? for help.
nix-repl> :lf .
Added 13 variables.

Une fois chargé, on peut accéder aux outputs avec outputs.<type de conf>.<system>.<nom>

Tips : Vous pouvez appuyer deux fois sur Tab pour avoir de l’aide.

Vous pouvez aussi facilement vérifier votre configuration nix avec la commande

1

nix flake check .

Fonctionnement des environnements de développement

Utiliser un devShell

Les devShells permettent de configurer des environnements par défaut. On peut y accéder avec l’aide de la commande nix develop [path du flake]#[nom de l'environnement].

Ex: nix develop .#default

Le path par défaut est déjà le répertoire courant et la configuration utilisée par défaut est également default Donc la commande nix develop suffit dans notre cas, mais si on configure par exemple outputs.devShells.<system>.monshell. Dans ce cas, il faudra utiliser nix develop .#monshell ou nix develop /home/user/monflake#monshell

On peut accéder aux environnements utilisés pour développer n’importe quel package nix. Par exemple, si l’on souhaite aider au développement de ruby. On peut lancer une console de développement avec la commande nix develop nixpkgs#ruby ou même voir la configuration d’un package avec nix edit nixpkgs#ruby

On remarquera qu’ici j’utilise nixpkgs et pas le path du flake. Ça permet d’utiliser la configuration d’un package depuis nixpkgs directement.

Attention Pour des logiciels compilés, en général, il faut d’abord configurer le compilateur via les phases du logiciel. ex: configurePhase et ensuite compiler le logiciel ex: buildPhase . Les phases peuvent varier en fonction du logiciel.

Configurer son propre devShell

Voici une configuration de shell avec des commentaires pour expliquer le fonctionnement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

outputs = { self, nixpkgs, flake-utils }:
  # Génère une configuration avec l'ensemble des systèmes par défaut
  # aarch64-linux => ARM sur Linux
  # aarch64-darwin => M1, M2, M3, ... sur MacOS
  # x86_64-linux => AMD et Intel sur Linux
  # x86_64-darwin => Intel sur MacOS
  #
  # Pour configurer avec une liste précise de systèmes, vous pouvez utiliser cette fonction
  # flake-utils.lib.eachSystem ["aarch64-linux" " x86_64-darwin"] (system: [...])
  # Voir plus https://github.com/numtide/flake-utils
  #
  # Les éléments d'un tableau ne sont pas séparés par une virgule ex: [ 12 14 ]
  flake-utils.lib.eachDefaultSystem (system:
    let
      # Importe les packages pour le système.
      pkgs = import nixpkgs { inherit system; };
      # Le mot clef inherit équivaut à import nixpkgs { system = system };
      # On peut aussi inherit depuis autre chose
      # { inherit (pkgs.ruby) pname; } renverra { pname = "ruby" }
    in
    {
      devShells = rec {
        # rec Permet d'utiliser les variables dans le même attributs set
        # Exemple:
        #         { a = 12; b = a + 2; } => error: undefined variable 'a'
        #     rec { a = 12; b = a + 2; } => { a = 12; b = 14; }
        #
        # Attention, car parfois, on peut faire des infinites recurse par accident.
        #
        # Exemple:
        #     rec { a = b + 2; b = a + 2; } => error: infinite recursion encountered
        #
        #     Car a dépend de b pour fonctionner, mais b dépend également de a

        # On utilise la fonction pkgs.mkShell qui contient tout ce qui nous faut pour créer notre environnement de travail
        default = pkgs.mkShell {
          # On rajoute des dépendances pour la compilation comme les librairies
          inputsFrom = with pkgs; [ openssl ];
          # On rajoute des binaires ou des librairies pour l'execution
          packages = with pkgs; [ redis minio ];
          # with pkgs permet d'éviter de faire [ pkgs.redis pkgs.minio ]

          # On créer une variable d'environnement
          MY_CUSTOM_ENV_VAR = "test";

          # Parfois nécessaire pour lancer des projets avec des librairies comme Ruby par exemple.
          # *_LIBRARY_PATH permet de dire à l'OS ou chercher les librairies.
          # Il faut le rajouter par exemple si on rencontre le soucis `Could not open library 'libsodium.so.23'`
          # LD_LIBRARY_PATH => Linux
          # DYLD_LIBRARY_PATH => MacOS
          LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);
          DYLD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);

          # Parfois nécessaire pour configurer des projets comme Ruby avec bundle
          # Certaines gems Ruby génèrent un fichier .c avec du code en dure et surtout un `#include <malib.h>` dedans.
          # Sauf qu'ils utilisent pas les outils de configuration du compilateur fournis par les OS. Donc, il faut créer des variables d'environnements pour dire au compilateur ou chercher les fichiers requis.
          # C_INCLUDE_PATH => Pour le language C
          # CPLUS_INCLUDE_PATH => Pour le language C++
          C_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);
          CPLUS_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);

          # Le shellHook est un script lancé au lancement du shell
          shellHook = ''
            echo "Votre shell est configuré avec MY_CUSTOM_ENV_VAR = $MY_CUSTOM_ENV_VAR"
          '';
        };
      };
    });

Liens utiles

Pour apprendre nix

Pour trouver des packages

Repository officiel de nixpkgs

Pour connaître l’état d’une Pull Request

Nix Flake
Dernière mise à jour le oct. 06, 2024 18:07 +0200
© 2024 Florian RICHER
Généré avec Hugo
Thème Stack conçu par Jimmy