173 lines
7.7 KiB
Markdown
173 lines
7.7 KiB
Markdown
---
|
|
options:
|
|
command_prefix: "pr:"
|
|
theme:
|
|
name: tokyonight-storm
|
|
override:
|
|
default:
|
|
# colors:
|
|
# foreground: "4c4f69"
|
|
# background: "ffffff"
|
|
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 -->
|
|
<!-- pr:column_layout: [1,2] -->
|
|
<!-- pr:column: 0 -->
|
|
# Définition des environnements de développement du package
|
|
* on défini un seul
|
|
environnement (**default**)
|
|
* la fonction <span style="color: p:base0F">**forEachSupportedSystem**</span> à pour
|
|
fonction de générer un élément pour chaque architecture supportée par le package
|
|
* ces architectures sont définie à la ligne 8 et correspondent aux architectures
|
|
supportée par nix.
|
|
* Dans cet environnement, on fournis les packages suivants
|
|
* **nodejs**
|
|
c'est un projet vue.js, donc faut bien un runtime
|
|
* **yarn**
|
|
ici on préfèrera yarn pour pouvoir utiliser yarn2nix afin de générer les
|
|
dépendances.
|
|
* webstorm
|
|
* je l'installe que pour ce projet, donc ça me permet de le garbage collecter
|
|
quand j'en ai pas besoin (merci nix)
|
|
* **yarn2nix**
|
|
* yarn2nix est un outil qui vas lire notre fichier package.json et générer
|
|
un fichier yarn.nix avec toutes nos dépendances packager pour nix, pour des
|
|
question de reproductibilité, lors du build avec nix, les outils n'ont pas accès
|
|
à internet, il n'est donc pas possible de juste faire un "yarn add".
|
|
<!-- pr:column: 1 -->
|
|
```file +line_numbers {13-18}
|
|
path: shoblog_code.nix
|
|
language: nix
|
|
```
|
|
<!-- pr:end_slide -->
|
|
|
|
<!-- pr:column_layout: [1,2] -->
|
|
<!-- pr:column: 0 -->
|
|
# Définition des packages
|
|
|
|
* d'une manière similaire aux **devShells**, on vas ici générer un package par
|
|
architecture supportée. Lors du build (qui se fait généralement localement),
|
|
nix va néanmoins builder uniquement le package correspondant à l'architecture
|
|
de la machine.
|
|
* Pour ce faire, on utilise la fonction <span style="color: p:base0F">
|
|
**mkYarnPackage**</span> qui fournit diverses options pour générer un package
|
|
manager par **Yarn**
|
|
* **name**: assez explicite, le nom du package générer
|
|
* **src**: les source sur lequel la fonction va se baser pour générer le package
|
|
* **PackageJSON**: package.json
|
|
* **yarnLock**: yarn.lock
|
|
* <span style="color: p:base0F">**yarnNix**</span>: Ah ! C'est ici qu'on
|
|
retrouve notre fameux **yarn.nix**.
|
|
* En fait, lors du process de build et pour
|
|
pour des raisons de reproductibilité, les programmes n'ont pas accès à internet. Chez nix,
|
|
toutes les dépendances doivent être connue et regroupée à l'avance. Pour ce faire,
|
|
**yarn2nix** nous génère un fichier **yarn.nix** définissant sous forme de package
|
|
nix toutes les dépendances de notre projet, ainsi lors du build, nix vas toutes
|
|
les pull, donner le résultat à mkYarnPackage qui vas les installer dans son
|
|
environnement de build.
|
|
* Et pour finis, les phases de notre build. Par défaut, **mkYarnPackage** va
|
|
juste chercher à build un binaire basée sur la configuration de notre package.json,
|
|
dans notre cas
|
|
<!-- pr:column: 1 -->
|
|
```file +line_numbers {20-45}
|
|
path: shoblog_code.nix
|
|
language: nix
|
|
```
|
|
<!-- pr:end_slide -->
|
|
|
|
<!-- pr:column_layout: [1,2] -->
|
|
<!-- pr:column: 0 -->
|
|
## buildPhase
|
|
Le build d'un package sous nix est découpé en plusieurs phases, si la plupart
|
|
sont généralement transparente, celons le cas, certaines ont besoin d'être
|
|
override en fonction des besoins. Ici, l'on cherche à packager des assets statiques, donc:
|
|
* première étape, appeler `runhook preBuild`, rien à voir avec notre affaire, mais
|
|
cela permet à d'éventuel futur dev de venir surcharger notre package sans toucher
|
|
à notre buildphase, chaque phase à des pré et post hook de la même manière.
|
|
* `mkdir $TEMPDIR/dist`, on créer un dossier temporaire pour nos fichiers de build
|
|
* `yarn run build --outDir $TEMPDIR/dist`, on run notre script de build en précisant
|
|
notre dossier temporaire comme output
|
|
* et on run le hook de postBuild
|
|
|
|
<!-- pr:column: 1 -->
|
|
```file +line_numbers {29-34}
|
|
path: shoblog_code.nix
|
|
language: nix
|
|
```
|
|
<!-- pr:end_slide -->
|
|
|
|
<!-- pr:column_layout: [1,2] -->
|
|
<!-- pr:column: 0 -->
|
|
## installPhase
|
|
Cette phase a pour rôle de placer les fichiers résultant du build dans le store
|
|
de nix, je passe sur les hook qu'on à déjà vu précédemment
|
|
* `mkdir -p $out/`, **$out** est une variable spécifique à cette phase de build
|
|
qui pointe vers le dossier final attribué par nix pour notre package.
|
|
* `cp -r $TEMPDIR/dist/ $out/`, on copie les fichiers de notre build dans le
|
|
dossier ainsi créer et zou ! :3
|
|
|
|
<!-- pr:column: 1 -->
|
|
```file +line_numbers {36-41}
|
|
path: shoblog_code.nix
|
|
language: nix
|
|
```
|
|
|
|
<!-- pr:end_slide -->
|
|
## Résultat
|
|
Hop, un petit coup de `nix build` et sous vos yeux ébahis, nix nous pull toutes
|
|
nos dépendances, build notre projet et le place au chaud dans son store. \
|
|
Bon c'est vachement bien tout ça, mais pourquoi faire ?
|
|
On verra les avantages en détails dans d'autres articles (peut-être même dès demain ?
|
|
mystère mystère...) mais voici déjà quelques bullet points
|
|
* Reproductibilité
|
|
* Nix nous assure que, pour des entrées données, le résultat sera toujours le
|
|
même, ainsi, il nous est possible de pin un commit spécifique de nixpkgs pour
|
|
figer la release de notre paquet dans le temps. Contrairement à un package
|
|
manager plus classique (apt par exemple), lors du build de votre paquet, vous
|
|
serez ainsi assurer de toujours pull la même version de node tant que l'on
|
|
update pas le flake.lock du projet.
|
|
* Isolation
|
|
* Nix installe chaque dépendance dans un dossier appellé le **store**, chaque
|
|
dépendance étant installer dans un dossier au hash unique basé sur le nom du
|
|
package et sa version. Ce qui fait qu'il est parfaitement possible d'avoir
|
|
deux projets utilisant deux versions de node différentes sans aucun problème,
|
|
et ce sans avoir besoin de docker, d'environnement virtuel ou de faire mumuse
|
|
avec des liens symboliques. Bonus, si un autre projet nécessite la même version
|
|
de node, nix va simplement utiliser celle déjà installer, ce qui évite les
|
|
duplicatas.
|
|
* Tracking
|
|
* étant donné que toutes les dépendances de chaque package sont déclarées dans
|
|
le `flake.nix`, il suffit de lire ce dernier pour savoir quels paquets sont
|
|
nécessaires à son déploiement. De plus, si l'on enlève un paquet de l'environnement,
|
|
nix vas pouvoir checker si ses dépendances sont utiliser par d'autres paquets,
|
|
et dans la négative, les supprimer pour économiser la place.
|
|
* Configuration
|
|
* Un peu hors du scope de cet exemple, mais il est possible de définir une
|
|
fonction d'override pour un paquet afin de permettre à l'utilisateur final
|
|
de ce dernier de spécifier des paramètres à ce dernier au moment du build.
|
|
Que ce sois l'utilisation d'une version spécifique de node, ou une clé d'API
|
|
par exemple.
|
|
* en utilisant NixOS, il est possible de définir des **modules** que
|
|
l'utilisateur peut importer dans la configuration de son système afin de
|
|
déclarer des services, installer et configurer d'autres packages, configurer
|
|
des interfaces réseaux, ect... Cela peut permettre d'automatiser grandement
|
|
le déploiement de certains projets et de grandement organiser ses configurations
|
|
(comme avec la déclaration de virtualhost nginx par exemple, teasing teasing...)
|