Cet outil vient de tuer Homebrew.

La majorité des développeurs macOS évoluent dans une pile d'outils précaire. Homebrew installe tout, de `git` à `ffmpeg`, ASDF ou NVM jonglent avec les versions des langages, et un mélange de scripts shell, de clones de MacUp ou de « gists » privés "bootstrap" essaie de tout assembler. Chaque nouveau Mac devient un projet de week-end consistant à copier-coller des commandes `brew install` et à espérer que `brew bundle` corresponde toujours à la réalité.

Cette réalité s'efface presque immédiatement. Vous installez un utilitaire ponctuel pour un projet client, modifiez un paramètre `defaults write`, bloquez Node 18 pour une application et Node 20 pour une autre, puis vous oubliez le tout. Six mois plus tard, votre ordinateur portable fonctionne, mais vous n'avez aucune idée du pourquoi, et votre `Brewfile` ou vos dotfiles ne capturent qu'environ 60 % de ce qui compte réellement.

Le dérive de configuration est la taxe silencieuse sur chaque Mac que vous possédez. Personne ne suit quel service obscur `launchctl` vous avez désactivé, quelle version de Python vous avez installée avec pyenv plutôt qu'avec Homebrew, ou quel fichier plist de `~/Library` vous avez modifié à 2 heures du matin. Essayez de recréer cette machine sur un nouveau Mac et vous découvrirez que "même configuration" est en réalité une approximation, et non un état reproductible.

Les développeurs essaient en permanence de se sortir de cette situation avec des fichiers `setup.sh` de plus en plus élaborés et des dépôts de dotfiles. Vous pourriez avoir : - `brew bundle dump` pour faire un instantané des paquets - Des configurations ASDF ou NVM pour les environnements d'exécution - Un script `bootstrap` qui crée des liens symboliques vers les dotfiles et exécute plus de 20 commandes

Tout cela reste impératif : « faites ceci, puis cela, puis peut-être cette autre chose si ce n'est pas installé. » Manquez une étape, ou exécutez-le sur une version légèrement différente de macOS, et l'ensemble du processus commence à vaciller.

Le rêve semble très différent : un seul fichier sous contrôle de version qui décrit l'ensemble de votre environnement. Une configuration déclarative qui indique "ce Mac possède ces paquets, ces applications du Mac App Store, ces versions de langue et ces paramètres système", et un outil qui fait correspondre la réalité au fichier—sur n'importe quel Mac, à tout moment.

Comparé à cela, les flux de travail centrés sur Homebrew d'aujourd'hui ressemblent à la création d'une maison de cartes. Une mauvaise mise à jour, un robinet manquant, un avertissement silencieux de `brew doctor`, et votre configuration "standard" s'effondre en heures de réparation manuelle.

Homebrew donne l'impression d'un commandement : `brew install vim`, appuyez sur entrer, espérez que rien n'explose. Nix ressemble à un contrat. Vous décrivez l'état exact dans lequel votre Mac doit se trouver, et le travail de Nix est de faire correspondre la réalité à cette description, à chaque fois, sur n'importe quelle machine.

« Purement fonctionnel » sonne académique, mais pour les développeurs, cela se traduit par une seule chose : prévisibilité. Étant donné le même fichier de configuration et les mêmes entrées, Nix produit toujours les mêmes sorties—versions identiques, dépendances identiques, paramètres système identiques. Pas de mises à jour surprises, pas de fantômes de « ça fonctionne sur ma machine ».

Les outils traditionnels comme Homebrew évoluent dans un monde impératif. Vous exécutez une série de commandes uniques : - `brew install vim` - `brew upgrade` - `brew uninstall node`

Votre système devient la somme de chaque commande que vous avez jamais tapée, plus les effets secondaires que ces commandes ont eus. Oubliez une étape sur un nouveau Mac, et votre configuration dérive silencieusement de l'original.

Nix transforme cela en un modèle déclaratif. Vous maintenez une configuration qui stipule, dans le code, "ce Mac doit avoir `vim`, `neovim`, `nodejs-20`, `python-3.11`, ces dotfiles et ces paramètres système." Nix construit ensuite cet état à partir de zéro, comme si votre Mac était une VM fraîche, et l'applique de manière atomique.

Atomique est le mot clé. Les installations Nix se trouvent dans des chemins de stockage adressés par le contenu, de sorte que les mises à jour deviennent des transactions : soit la nouvelle configuration se construit avec succès, soit votre système reste exactement tel qu'il était. Si une mise à jour casse votre chaîne d'outils, vous exécutez une simple commande de retour en arrière et rétablissez l'ensemble de l'environnement—binaries, bibliothèques, configuration—comme une machine à remonter le temps locale.

Parce que chaque paquet vit dans son propre préfixe isolé, Nix installe avec plaisir plusieurs versions du même outil sans conflit. Vous pouvez avoir trois versions différentes de `node`, un `python` fixe pour un projet et un `git` à la pointe pour un autre, le tout coexisté sans scripts shim ni astuces de gestion de versions.

Surtout, Nix traite l'ensemble de votre configuration comme du code. Vos fichiers Nix deviennent une pile personnelle d'Infrastructure-as-Code : outils en ligne de commande, applications GUI, installations depuis le Mac App Store, configuration de shell, même les ajustements `defaults write`, le tout sous contrôle de version. Un nouveau Mac cesse d'être un projet de week-end et devient un `git clone` et une seule commande de construction.

Nix a vu le jour en 2003 comme un projet de doctorat néerlandais dirigé par Eelco Dolstra, une expérience dans la gestion de paquets purement fonctionnelle. Cette recherche s'est matérialisée sous la forme du langage Nix, puis de NixOS, une distribution Linux où chaque paquet, service et modification du système découle de configurations Nix déclaratives. Dans les années 2010, NixOS était devenu une alternative sérieuse pour des systèmes Linux reproductibles dans le milieu académique, DevOps et les laboratoires domestiques, soutenu par des milliers de contributeurs et plus de 80 000 paquets dans Nixpkgs.

Les développeurs Mac ont principalement regardé de côté jusqu'à l'arrivée de Nix Darwin. Construit comme une couche au-dessus de Nix, Nix Darwin traduit ces modules de style NixOS en quelque chose qui comprend le cœur Unix de macOS, Darwin. Il gère les démons de lancement, les agents utilisateurs, les environnements de shell et les paramètres système de la même manière que NixOS gère les unités et services `systemd`.

En termes de relations, pensez en trois couches. Nix est le moteur : le gestionnaire de paquets et le langage. Nixpkgs est le vaste référentiel de définitions de logiciels et de modules de configuration. Nix Darwin est le liant qui fait correspondre ces abstractions à macOS, exposant des options pour tout, des outils CLI de style `brew` aux paramètres d’auto-cacher du Dock.

Au lieu de disperser l'état dans `/usr/local`, des fichiers dot aléatoires et des ajustements plist cachés, Nix Darwin centralise le contrôle. Un seul flocon peut déclarer : - Quels paquets de Nixpkgs installer - Quels paramètres par défaut du système Mac configurer - Quels services activer ou désactiver

Nix Darwin n'est pas un simple outil de week-end. Il est hébergé sur GitHub avec des centaines de contributeurs, un tri actif des problèmes et des versions régulières qui suivent les nouvelles versions de macOS. Les utilisateurs avancés l'intègrent dans leurs dépôts My Dotfiles, puis reconstruisent des Macs entiers avec une seule commande `darwin-rebuild switch` après une installation propre.

Quiconque souhaite voir comment cet écosystème s'assemble peut commencer par le site officiel de Nix & NixOS et le dépôt Nix Darwin. Ensemble, ils transforment macOS d'un flocon mappé à la main en un artefact que vous pouvez versionner, examiner et restaurer comme tout autre code.

Les flocons ressemblent à des céréales pour le petit-déjeuner, mais dans le monde de Nix, ils représentent le standard de facto de la configuration reproductible pour la communauté. Au lieu d'un mélange de scripts shell, de Brewfiles et d'outils de synchronisation, un seul flocon définit exactement à quoi doit ressembler votre Mac : outils, services, voire les applications Mac App Store que vous attendez. Vous disposez d'une source unique de vérité, et Nix s'occupe du reste.

Au centre se trouve `flake.nix`, un manifeste en texte brut écrit dans le langage Nix. Il repose sur deux grandes idées : entrées et sorties. Les entrées décrivent les dépendances de votre configuration ; les sorties décrivent ce que votre configuration produit.

Les entrées incluent généralement : - `nixpkgs` (la collection principale de paquets Nix) - D'autres Flakes de la communauté (comme les modules `nix-darwin`) - Vos propres Flakes partagés pour le travail ou des projets annexes

Les sorties transforment ces ingrédients en quelque chose que vous pouvez réellement exécuter. Un `flake.nix` pourrait exposer : - `packages` pour des outils CLI et des environnements d'exécution de langages - `darwinConfigurations` pour des configurations complètes macOS - `devShells` pour des environnements par projet

Exécutez `darwin-rebuild switch --flake .#votre-nom-d'hôte` et Nix construit les sorties déclarées dans votre flake, puis les active sur votre Mac. Remplacez `vim` par `neovim`, ajoutez `zellij`, reconstruisez, et votre système passe à l'état nouveau en une seule opération. Aucune installation manuelle avec `brew`, aucune interrogation sur le gestionnaire de versions contrôlant quel binaire.

Si `flake.nix` est la recette, `flake.lock` est le garde-manger sous vide. Ce fichier JSON fixe chaque entrée à une révision Git ou une version exacte, donc lorsque vous et vos coéquipiers construisez à partir du même dépôt, vous obtenez des chaînes d'outils et des configurations identiques. Pas de surprises du genre "ça fonctionne sur ma machine", pas de mises à jour silencieuses parce que `nixpkgs` a évolué du jour au lendemain.

Il y a un piège : les Flakes restent officiellement « expérimentaux » dans Nix, cachés derrière un drapeau de fonctionnalité. La réalité sur le terrain est différente. Presque chaque guide moderne de Nix, chaque modèle de démarrage et chaque configuration sérieuse — y compris des configurations populaires comme Nix Darwin sur Mac — suppose que vous utilisez les Flakes, car ils sont suffisamment stables, puissants et rendent enfin l’histoire de la reproductibilité de Nix complète.

L'installation de Nix sur macOS commence comme tout autre outil de développement : un installateur téléchargeable via curl, une barre de progression, et une brève attente pendant qu'il s'intègre à votre shell. Après cela, le flux de travail diverge immédiatement de l'univers Homebrew. Vous créez un répertoire `~/.nix` (ou similaire), puis vous y déposez un flocon Nix Darwin de démarrage récupéré sur GitHub ou à partir d'un modèle comme My Dotfiles.

Ce fichier flake devient la source de vérité de votre Mac. Il déclare quels packages, services et paramètres système doivent exister sur la machine, des outils CLI aux applications Mac App Store. Au lieu d'exécuter des commandes `brew install` au cas par cas, vous éditez une seule expression Nix qui décrit l'état complet du système.

Tout gravite autour d'un seul commandement : `darwin-rebuild switch`. Nix lit votre flocon, évalue la configuration, construit tout ce qui manque et change votre Mac vers cet nouvel état de manière atomique. Pas besoin de fouiller dans l'historique du shell, pas de devinettes sur le fichier de configuration qui a activé quoi.

Modifiez une ligne dans la configuration, exécutez `darwin-rebuild switch`, et la machine s'ajuste. Dans la vidéo, l'hôte remplace `vim` par neovim dans la liste des paquets et ajoute `zellij` (mal orthographié en « zelage » dans la transcription) bien qu'il n'ait jamais été installé auparavant. Après la reconstruction, `nvim` est disponible sur tout le système, `zellij` s'exécute instantanément, et l'ancien binaire Vim ne provient plus de Nix Darwin.

Cette boucle de modification et de remplacement transforme la configuration en révision de code plutôt qu'en rituel. Vous souhaitez tester un outil temporairement ? Ajoutez-le au flocon, reconstruisez, essayez-le, puis retirez-le et reconstruisez à nouveau ; Nix effectue le nettoyage des versions inutilisées. Chaque changement est explicite, contrôlable par version et répétable sur les Macs.

Comparé à une configuration Homebrew traditionnelle, cela remplace une multitude de commandes et de scripts. Une machine fraîche typique pourrait nécessiter : - 30 à 80 appels à `brew install` et `brew install --cask` - Un `brew bundle dump` ou une exportation MacUp - Des modifications manuelles des dotfiles et des paramètres par défaut de macOS

Avec Nix Darwin et les flakes, vous encodez tout ce rituel une seule fois. Un nouveau Mac n'a besoin que de Nix installé et du flake cloné ; `darwin-rebuild switch` reconstruit votre environnement en une seule fois, des outils CLI aux paramètres par défaut du système et aux applications du Mac App Store, sans chasse au trésor requise.

Homebrew pense en termes d'outils en ligne de commande et de casks ; Nix pense en termes de mondes entiers. Une fois que vous avez un flocon Nix Darwin en place, votre Mac cesse d'être un cas isolé et commence à se comporter comme un artefact de construction reproductible, de l'interpréteur que vous utilisez à la manière dont votre Dock s'anime.

La plupart des gens découvrent Nix à travers `nixpkgs` et ses dizaines de milliers de paquets CLI, mais la portée va beaucoup plus loin. Une seule flocon peut déclarer vos outils de développement, applications GUI, services système, polices et même agents de lancement, le tout figé sur des versions exactes afin qu'un Mac neuf en 2025 corresponde à votre ordinateur portable de 2023, bit par bit.

L'intégration avec le Mac App Store est souvent impressionnante. Avec Nix Darwin connecté, vous pouvez déclarer des applications par ID d'App et Nix les récupérera depuis le Mac App Store tant qu'elles sont liées à l'historique d'achats de votre identifiant Apple. Votre configuration peut littéralement indiquer "installer `409201541`" et vous obtiendrez Pages, ou "`497799835`" et vous obtiendrez Xcode, sans avoir besoin de cliquer manuellement dans le Mac App Store.

Ce mouvement remplace discrètement une grande partie de ce que MacUp ou des scripts de sauvegarde artisanaux tentaient de résoudre. Au lieu d'exporter un Brewfile et d'espérer vous souvenir des applications App Store que vous avez utilisées, votre flocon devient la liste canonique de tout ce qui devrait exister sur la machine, peu importe comment Apple le distribue.

Les modules Nix Darwin vont encore plus loin en traitant les préférences macOS comme du code. Vous pouvez déclarativement définir le comportement du Dock, le taux de répétition des touches, la fonction tap-to-click du trackpad, les options de visibilité du Finder et les coins actifs en utilisant des options Nix structurées plutôt que des commandes `defaults write` peu fiables. Une commande `darwin-rebuild switch` devient l’équivalent de cliquer à travers une douzaine de panneaux de Paramètres Système en une seule fois.

Cela transforme les rituels manuels d'installation en un seul commit. Nouvelle machine ? Clonez vos fichiers de configuration, exécutez une commande, et votre Dock se cache automatiquement, la répétition des touches atteint votre cadence préférée de 15 ms, et votre shell, les polices et le gestionnaire de fenêtres apparaissent exactement comme auparavant.

Quiconque est curieux de savoir jusqu'où cela peut aller peut explorer nix-darwin - Configuration système basée sur Nix pour macOS. Entre ces modules et un bon flake, Nix ne remplace pas seulement Homebrew ; il absorbe discrètement les outils de sauvegarde, les listes de vérification de configuration et des années de mémoire musculaire dans un seul script exécutable à volonté.

Les passionnés de Homebrew n'ont pas à renverser une table et à tout reconstruire dans Nix dès le premier jour. Une stratégie beaucoup moins stressante considère Nix comme le chef d'orchestre et Homebrew comme l'une des sections de l'orchestre. Vous conservez vos outils existants, mais vous confiez la planification et l'état à un seul fichier de configuration.

Les configurations modernes de Nix sur Darwin peuvent en fait gérer Homebrew elles-mêmes. Dans une flaque, vous activez le module Homebrew, le pointez vers votre installation existante, puis déclarez `brew.packages` et `casks` aux côtés de vos paquets Nix. Lorsque vous exécutez `darwin-rebuild switch`, Nix appelle `brew install`, `brew uninstall` et `brew upgrade` pour vous, si bien que votre monde Brew devient simplement une autre sortie reproductible.

Cette approche hybride crée un chemin de migration idéal. Vous pouvez commencer par déplacer les outils CLI principaux — `git`, `node`, `python`, `fzf`, `ripgrep` — dans `environment.systemPackages` ou Home Manager, tout en laissant les applications GUI sous forme de casks Brew. Au fil du temps, vous remplacez les formules Brew par des équivalents Nix au fur et à mesure que vous les trouvez dans nixpkgs.

Nixpkgs expose actuellement plus de 80 000 paquets, mais Homebrew Cask l'emporte toujours en termes de couverture des applications spécifiques à Mac. Cette longue traîne inclut des utilitaires obscurs, des outils de barre de menus de niche et des installateurs de fournisseurs uniques qui ne figureront peut-être jamais dans nixpkgs. Déclarer ceux-ci comme des casks Brew sous Nix signifie que vous ne perdez rien tout en standardisant le reste de votre infrastructure.

Une configuration typique de « pont » se compose de trois couches gérées depuis un seul flocon :

• 1Packages Nix pour tous les outils CLI essentiels et les environnements d'exécution des langages.
• 2Modules Nix pour les paramètres système par défaut et les fichiers de configuration.
• 3Casks Homebrew pour applications GUI et utilitaires de cas particuliers

Vous exécutez toujours `darwin-rebuild switch` comme votre source unique de vérité. En coulisses, Nix se met à jour, applique les paramètres par défaut de macOS, synchronise vos fichiers de configuration, puis lance Homebrew pour installer ou supprimer tout ce que vous avez listé, le tout sans que vous ayez à toucher directement à `brew`.

La plupart des gens abandonnent Nix exactement au moment où cette vidéo s'incline : la "courbe d'apprentissage vraiment, vraiment raide". Homebrew nécessite une seule commande pour installer `wget` ; Nix vous accueille avec un nouveau langage, un nouveau modèle mental et un arbre de répertoires qui ressemble à ce que votre Mac aurait englouti après une fonction de hachage. Les utilisateurs avancés appellent cet échange une bonne affaire ; tout le monde d'autre appelle cela un week-end perdu dans la documentation.

Première mur : le langage Nix lui-même. Il ressemble un peu à JSON et un peu à Haskell, puis fait des choses que aucun de ces deux langages ne fait. Vous écrivez des ensembles d'attributs, des lambdas et des modules juste pour dire "installer `neovim`", et de petites erreurs de syntaxe apparaissent souvent sous la forme d'erreurs de 10 lignes concernant "l'attribut ‘packages’ manquant."

Deuxième mur : concepts de programmation fonctionnelle que vous n'avez jamais demandés. Nix insiste pour que tout soit pur et immuable, donc au lieu de « exécuter ce script », vous définissez des dérivations qui décrivent ce que devrait être une construction. Cela a des avantages en matière de reproductibilité, mais cela vous oblige à penser en termes d'entrées, de sorties et d'évaluation, et non pas à « exécuter une ligne de commande bash et espérer ».

Puis vient le Nix store, la forêt de chemins adressés par le contenu de `/nix/store` qui rend Nix magique et frustrant. Chaque résultat de build vit sous un hachage comme `/nix/store/abcd1234-neovim-0.9.1`, ce qui garantit l'isolation mais rend les modifications ad hoc hostiles. Vous ne "modifiez pas simplement un fichier de configuration" ; vous modifiez un flocon, reconstruisez et laissez Nix collecter les anciennes générations.

Le débogage des dérivations ajoute une couche supplémentaire de douleur. Lorsque qu'un paquet échoue à se construire, vous êtes face à des expressions Nix, des scripts de construction, et parfois des particularités multiplateformes héritées de NixOS. Les erreurs de Homebrew indiquent généralement "dépendance manquante" ; les erreurs de Nix disent souvent "la valeur est une fonction alors qu'un ensemble était attendu" et s'attendent à ce que vous sachiez pourquoi.

Pour des installations simples, Nix semble vraiment excessif. Si vous avez seulement besoin de `node`, `python` et `ffmpeg`, la commande `brew install` de Homebrew paraît plus rapide, plus claire et beaucoup moins intrusive que d'activer les flakes, de configurer Nix Darwin et de commettre un `flake.nix` juste pour obtenir un shell. La vidéo montre même que cette configuration initiale s'étend sur plusieurs commandes, options et modifications de configuration avant que quoi que ce soit d'amusant ne se produise.

Parmi les fans, Nix a gagné un compliment indirect : le « pire gestionnaire de paquets, excepté tous les autres ». Vous payez d'avance en complexité, en documents obscurs et en erreurs déroutantes, et en retour, vous obtenez un système qui peut recréer l'intégralité de votre Mac à la demande. Pour de nombreux développeurs, cette puissance finit par l'emporter sur la douleur—juste pas dès le premier jour.

Le résultat incroyable avec Nix ressemble à ceci : un tout nouveau Mac passe de l'emballage à un poste de travail de développement entièrement équipé en moins de 10 minutes. Vous vous connectez à Git, clonez votre dépôt My Dotfiles, exécutez une seule commande `darwin-rebuild switch --flake .`, et regardez votre éditeur, vos shells, vos chaînes d'outils linguistiques, vos polices, et même les applications de l'App Store Mac réapparaître exactement comme avant. Plus besoin de chercher des installateurs, plus de "oh zut, j'ai oublié d'installer jq."

Sous le capot, Nix traite l'ensemble de votre environnement comme des données. Votre flocon Nix Darwin déclare chaque paquet, service et valeur par défaut de macOS sous forme de code, de sorte que l'état de votre machine devient une fonction pure d'un commit Git. Revenez à ce commit et Nix annule atomiquement vos outils, configurations et ajustements système d'un seul coup.

Pour les équipes, cela transforme l'intégration d'un nouveau membre en un simple commandement documenté au lieu d'un rituel de plusieurs heures. Un nouvel employé tire le dépôt, exécute le flake et se retrouve dans un environnement identique à la production et à celui de chaque autre ingénieur—même version de `node`, même `postgres`, mêmes outils CLI, mêmes dotfiles. L'excuse "ça fonctionne sur ma machine" disparaît lorsque "ma machine" est une construction Nix reproductible.

Le travail quotidien devient également plus sûr. Vous voulez essayer Python 3.13, une version à la pointe de `clang`, ou une nouvelle configuration `zellij` ? Vous les fixez dans une branche, exécutez `darwin-rebuild`, et Nix construit la nouvelle génération en parallèle avec l'ancienne. Si quelque chose ne fonctionne pas comme prévu, une simple commande de restauration rétablit la génération précédente, sans liens symboliques ou paquets partiellement désinstallés.

Ce modèle atomique encourage l'expérimentation que vous n'oseriez jamais tenter sur un système Homebrew réglé à la main. Vous pouvez maintenir : - Une flake "stable" pour le "travail" - Une flake "beta" avec de nouveaux outils - Des flakes par projet avec des dépendances fixées

Changer entre eux devient une question de secondes, et non d'un week-end à réinstaller les outils en ligne de commande Xcode.

Les développeurs documentent déjà ce flux de travail sur le terrain ; des guides comme Nix sur macOS – le meilleur Homebrew expliquent comment remplacer complètement Homebrew par des configurations Nix déclaratives. Une fois que vous avez expérimenté un Mac frais se matérialisant à partir d'un commit Git, chaque script de configuration ad hoc semble être un assemblage de votre environnement avec des pierres.

Curieux mais convaincu par la théorie de Nix ? Commencez par traiter Nix comme un environnement virtuel jetable et plus intelligent plutôt que comme une nouvelle religion pour votre Mac. Installez Nix, ouvrez un dossier de projet et exécutez `nix-shell -p <package>` pour créer un environnement isolé qui disparaît lorsque vous fermez le shell. Pas d'installations globales, pas de nettoyage `brew uninstall`, aucun risque pour votre infrastructure existante.

Utilisez cette commande comme vos roulettes d'entraînement. Besoin de `jq`, `nodejs` et `postgresql` pour un projet secondaire ? Exécutez `nix-shell -p jq nodejs postgresql` et travaillez à l'intérieur de ce shell. Vous obtenez des outils reproductibles par projet sans toucher à votre PATH système ou réécrire vos fichiers de configuration.

Une fois que cela semble normal, commencez à capturer ces environnements ad-hoc dans des fichiers `.nix` simples vérifiés dans votre dépôt. Un `shell.nix` minimal qui fixe `nodejs-20_x` et `pnpm` est déjà mieux qu'une ligne dans le README qui dit "installez Node d'une manière ou d'une autre." Les membres de l'équipe exécutent `nix-shell` et se retrouvent dans le même environnement exact, peu importe l'apparence de leur installation Homebrew.

Quand vous êtes prêt à découvrir à quoi ressemble un Mac entièrement déclaratif, explorez les configurations des autres. Parcourez Mes Dotfiles de l'auteur de la vidéo sur GitHub : Mes Dotfiles. Ensuite, recherchez sur GitHub `nix-darwin flake.nix` et étudiez comment les gens les connectent :

• 1Modules `nix-darwin` pour les services système
• 2`home-manager` pour les fichiers de configuration au niveau utilisateur
• 3intégration `mas` pour les applications Mac App Store

Traitez ces dépôts comme une documentation vivante. Copiez un petit élément—une police, un outil CLI unique, un paramètre par défaut du système—dans votre propre flocon et exécutez `darwin-rebuild switch`. Si cela casse, vous restaurez un fichier et vous revenez, sans séance de `brew doctor` nécessaire.

Voici donc la question inconfortable : le confort à court terme de `brew install` justifie-t-il un futur où votre Mac reste un flocon unique que vous priez pour qu'il ne meure jamais ? Ou êtes-vous prêt à passer un week-end à apprendre Nix afin que votre prochain ordinateur portable, votre prochain emploi et votre prochaine installation propre deviennent un rituel d'une seule commande au lieu d'une chasse au trésor de plusieurs semaines ?

Qu'est-ce que Nix et en quoi est-il différent de Homebrew ?

Nix est un gestionnaire de paquets fonctionnel qui utilise un fichier de configuration déclaratif pour définir l'état complet de votre système. Contrairement aux commandes impératives de Homebrew (`brew install`), Nix construit votre environnement à partir d'un manifeste, garantissant qu'il soit reproductible et cohérent partout.

Nix peut-il remplacer complètement Homebrew sur macOS ?

Oui, pour de nombreux développeurs, Nix (via Nix Darwin) peut remplacer Homebrew, les gestionnaires de version et les gestionnaires de dotfiles. Il peut même gérer Homebrew lui-même pour installer des applications GUI ou des paquets qui ne sont pas encore dans le dépôt Nixpkgs, offrant ainsi un point de contrôle unique.

Qu'est-ce que les Nix Flakes et pourquoi sont-ils importants ?

Les Nix Flakes sont la méthode moderne et standard pour définir les projets Nix. Ce sont des manifestes déclaratifs qui verrouillent les dépendances, rendant vos configurations autonomes et parfaitement reproductibles, ce qui constitue un avantage majeur par rapport à la gestion traditionnelle des paquets.

Est-ce que Nix est vraiment difficile à apprendre ?

Oui, Nix présente une courbe d'apprentissage notoirement raide en raison de son langage de programmation fonctionnelle et de nouveaux concepts tels que les dérivations et le magasin Nix. Cependant, ses partisans soutiennent que l'investissement initial en vaut la peine grâce à un contrôle et une reproductibilité sans pareil.