Pourquoi adopter les devShells Nix pour des environnements reproductibles
Nix
Loading content...
Après des années à me battre avec des conflits de versions, des environnements qui divergent entre collègues et des « ça marche sur ma machine » interminables, j'ai découvert Nix. Et pour moi, c'est une révolution dans la gestion des environnements de développement.
Contrairement aux gestionnaires de paquets traditionnels que j'ai tous essayés (Homebrew, apt, conda, nvm...), Nix adopte une approche purement fonctionnelle qui garantit enfin la reproductibilité des builds et des environnements, du laptop à la CI jusqu'à la production.
Nix, c'est à la fois :
Sa particularité clé : chaque paquet (et environnement) est construit dans un chemin unique du store Nix, dérivé de l'ensemble de ses dépendances de build. Deux builds avec les mêmes entrées produisent les mêmes sorties, au même chemin — c'est la base de la reproductibilité.
Les devShells sont des environnements de développement par projet, décrits en Nix, que l'on active à la demande. Pour moi, ils ont résolu quatre galères quotidiennes que je vivais depuis des années.
/usr/local, et ne casse pas d'autres projets.flake.lock fige précisément les entrées utilisées. Toute l'équipe travaille sur les mêmes versions.nix develop → c'est prêt. Fini les longues sections « Installation » dans le README.Avant Nix :
Avec Nix :
task test, task fmt, task check)Grâce aux flakes et à direnv/nix-direnv, chaque projet définit précisément ses outils et bibliothèques. En entrant dans le dossier, l'environnement adéquat est chargé automatiquement, sans polluer le système global.
Ce que j'ai pu faire concrètement, en parallèle sur ma machine :
Terminé le casse-tête des versions système globales !
flake.nix :
{
description = "devShell Nix minimal";
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";
outputs = { self, nixpkgs }: let
system = "x86_64-darwin"; # ou x86_64-linux / aarch64-darwin
pkgs = import nixpkgs { inherit system; };
in {
devShells.${system}.default = pkgs.mkShell {
buildInputs = [ pkgs.nodejs_20 pkgs.python311 pkgs.git ];
# Variables d'environnement et hooks optionnels
shellHook = ''
echo "[devshell] Node: $(node -v), Python: $(python3 --version)";
export PIP_DISABLE_PIP_VERSION_CHECK=1
export UV_NO_CACHE=1
'';
};
};
}
.envrc :
# Option A: direnv de base
use nix
# Option B (recommandée): nix-direnv pour des activations instantanées
# use flake
Ensuite :
direnv allow # à exécuter une fois
Les activations suivantes sont instantanées avec nix-direnv (cache de shells).
Nix permet l'installation simultanée de multiples versions d'un même paquet, sans hacks. Cette « navigation dans le temps » est idéale pour maintenir des projets legacy tout en développant avec les versions les plus récentes.
Avec des définitions déclaratives et le fichier de verrouillage (flake.lock), j'ai la garantie que l'environnement sera identique partout où je l'utilise :
En local : Mon MacBook, celui d'un collègue, ma VM Linux - même versions, même comportement.
En CI : GitHub Actions, GitLab CI, peu importe - la CI utilise exactement les mêmes outils que moi en local.
Dans les environnements éphémères : Le plus bluffant, c'est avec des outils comme Devin.ai. Je peux partager mon flake.nix et l'IA dispose instantanément du même environnement que moi, sans installation manuelle, sans setup complexe.
Résultat : plus de "ça marche en local mais pas en CI", plus de temps perdu à synchroniser les versions entre développeurs et systèmes automatisés.
Onboarding quasi instantané :
nix developC'est d'ailleurs l'approche que nous avons adoptée en équipe : j'ai commencé par proposer un simple flake.nix sur un projet pilote, sans forcer personne. Résultat : adoption progressive et naturelle, sans friction.
Nix remplace efficacement une myriade d'outils :
Une commande pour tout installer sur une nouvelle machine, une logique unique pour toutes les stacks.
Serveurs de développement : Plus besoin de supplier l'admin système pour installer la bonne version de Node ou Python. Je déploie mon flake.nix, et l'environnement est identique à celui de mon laptop.
Avec des IA comme Devin : C'est là où ça devient magique. Je partage mon environnement Nix, et l'IA dispose instantanément du même setup que moi. Pas de "comment installer X", pas de différences d'environnement.
En CI/CD : Fini les problèmes de versions entre ma machine et la CI. Même Nix, même environnement, mêmes résultats.
Compléments utiles :
devenv.sh (Cachix) : surcouche ergonomique pour services locaux (DB, queues) et scripts d'équipeprocess-compose : orchestration de plusieurs processus de dev dans le shellMalgré cela, mon retour sur investissement a été net en productivité et sérénité.
system (ex. via flake-utils).L'écosystème Nix dépasse les 120 000 paquets. De plus en plus d'équipes que je rencontre l'adoptent, que ce soit en production ou juste pour standardiser leurs environnements de dev.
Pour moi, Nix a été un game changer. Fini le "ça marche sur ma machine", fini les heures perdues à débugger des conflits de versions, fini les onboardings pénibles.
Aujourd'hui, je ne conçois plus de démarrer un projet sans un devShell Nix. C'est devenu aussi naturel que de créer un README.
Oui, j'ai passé quelques weekends à comprendre les concepts — mais le gain en sérénité au quotidien est inestimable. Et quand un collègue me dit "ton projet ne fonctionne pas chez moi", je sais que c'est juste qu'il n'a pas encore fait nix develop 😉